Dealing With Metadata and Upgrades

Eventually, though, you may need a different database, either for schema changes or content changes.

You can handle this via migrations as normal. However, not only are you responsible for changing the schema but also for adjusting the content to take that new schema into account. And, if you want new or modified content, you will need to handle that as well.

An alternative is to add fallbackToDestructiveMigration() to the Room.databaseBuilder() configuration. This says “if we cannot find migrations to handle version changes, start over from scratch”. And, if you are using createFromAsset(), this means that Room will delete the existing database and make a new copy from the now-current asset. This works, though it has problems if your database is not a simple copy of the asset, as we will see in the next section.

Room uses the room_master_table to track Room-specific metadata, along with android_metadata that is set up and managed by the framework copy of SQLiteDatabase. For an initial deployment, you do not need these tables — the copy in PackagedFTS does not have them, for example. Room will create them automatically.