Search code examples
androiddatabasemigrationandroid-room

Android Room where is DB version stored?

Refering to: https://developer.android.com/training/data-storage/room/prepopulate#migrations

I want Room to remove my version 2 database and install a brand new version 3 database when updating from version 2 to version 3.

It says that for fallback migration to work you need "a prepackaged database file that is on version 3." when migrating from version 2 to 3.

Where is that version stored? The createFromAsset method takes a .db file and I cannot find a version in there. There is only the identifier_string which relates to the schema but can stay the same across versions.

Or is a new version only valid if the schema changes? How would I then trigger a migration if I e.g. just added some more entries to my database (e.g. by adding a new product)?

Solution

  • There are 2 places where the version number is stored.

    In the code, i.e. the version number that you specify in the @Database annotation.

    And in the actual database header, the first 100 bytes of the database file.

    The specific location, within the header, an offset of 60 bytes from the start and is 4 bytes in length. SQLite calls the the user_version

    It can be retrieved and or set by using the user_version PRAGMA, it could also be set or retrieved by opening the file itself and accessing or manipulating the value in the file.

    The SupportSQliteDatabase class also has the methods getVersion and setVersion.

    • These two would probably not be of use though.

    Some of the available SQLite Tools, which you would typically use for creating and maintaining a pre-packaged database, allow this to be easily changed

    • e.g. DB Browser for SQlite has :-
      • enter image description here

    Or is a new version only valid if the schema changes? How would I then trigger a migration if I e.g. just added some more entries to my database (e.g. by adding a new product)?

    Simply updating the version number in the @Database annotation is all that is required to initiate a Migration, a schema change itself does not trigger the Migration.

    Rather a schema change will be recognised as Room generates a hash of the schema as part of the code. This hash is compared against a hash that is stored in the database in the table room_master. The hashes mismatch them Room sees a change and will then expect that a Migration is provided, if not then an exception is raised and the App crashes.

    The Migration can do nothing if required.

    AutoMigrations are similar except that the Migration code is generated automatically, although it needs in the circumstances of an ambiguity (e.g. a column rename) to be provided with additional information via migration specs.

    Obviously you cannot use a manual and an AutoMigration together.