Android Inconsistent DB Schema when migrating from SQLite to Room.

Postmortems | Links:

Android Inconsistent DB Schema when migrating from SQLite to Room.

LESSON LEARNED: Every team should establish a communication channel with other teams to favor collaboration and contribution. Verbal communication is not effective/productive and a more formal process should be defined. Define boundaries of component ownnership.

“Develop a passion for learning. If you do, you will never cease to grow.”

Platform/Client

  • Android

Context Situation

In our Android client application, we have 2 main languages as part of our domain Logic: Scala and Kotlin (which at the time of writing the migration to the last one is a WIP). The interoperability is a bit complicated between them because of the lack of support for Scala on the Android ecosystem. Both languages are using one shared source of truth as a data store: SQLite DB.

In the effort of migrating everything to a new DB called Room, we bumped into issues, especially since it did not make any sense to keep both databases with duplicated data which would case inconsistency and a maintainance Nightmare.

Process

We made Room the main go to for databases by concatenating the migrations from both systems and ensuring Room knew about the database schema so it could create the tables necessary and make it easier for the old code and new code to read from one database irrespective of how they maintained models around the data. In essence, to keep the same data structure but changing the technology behind it.

Issue Summary

By migrating the schema from SQLite to Room, we got into an inconsistent state. Here is why:

  • We make asumptions that both DBs would work exactly the same, but for SQLite we were doing a lot of manual stuff and for Room, there is an underlying framework doing a lot for us.
  • A mistake made with null values as default ones, when translating from the old schema format to the new one.

This situation led to a constant unsuccesful upgrade of the DBs, keeping the old schema (automatically downgrading), so when trying to read/write information through our Data Layer, our client, which heavily relies on offline data, would crash, making the application completely useless.

Impact

The already mentioned context was critical for rewriting the Android Client to Kotlin. And in order to test this scenario the Android Team relied on QA Team infrastructure to perform regression tests. While the intention was to test this critical path, because of misscommunication, this led to 2 days of development unproductivity by runs being cancelled all the time.

Resolution

Both teams involved (Android and QA) agreed on establishing a communication path for the future in order to facilitate communication and perform these runs in an easier way.

Lessons Learned

  • Every team should establish a communication channel with other teams to favor collaboration and contribution.
  • Define boundaries of component ownnership (in this case QA infrastructure belongs to QA and any attempt to use it should be properly communicated).
  • Verbal communication is not effective/productive and a more formal process should be defined.

Supporting Information