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.
Prev Table of Contents Next
This book is licensed under the Creative Commons Attribution-ShareAlike 4.0 International license.