Let's say I have 2 migrations (1-->2, 2-->3). If a new user comes along and installs the app, will all the migrations be run, or will they just get the version 3 schema database?
They'll just get version 3. Databases internally track their database version and that is what Room uses to check if a migration is needed. In the case of a brand new database, Room just starts the user at the version of the database you specify.
Related
Should I increment the value of the Room database version if I change the content of the database when its migration strategy is set to "fallback to destructive migration"?
Following changes made to database:
Some columns are removed.
Content of some rows is updated in the database file that is stored in assets.
Yes. You should update the version of the database even with fallback to destructive migration strategy. Room uniquely identifies every database version with an "identity hash string", which is kept in a configuration table.
Keeping the database version unchanged will cause the app to crash with an IllegalStateException. Internally Room checks the identity of the database comparing the identity hash of the current version vs the the one stored in the table called "room_master_table".
You can learn more about this in the below article which also explains in detail how to handle version change and testing.
Reference: https://medium.com/androiddevelopers/understanding-migrations-with-room-f01e04b07929
UPDATE: It is interesting that the app crashed in some users, but for some users including me, it didn't crash. So it's better to update the version of the database even though its migration strategy is fallback to destructive.
From my experience, it seems we don't have to increment the value of Room database version when its migration strategy is set to "fallback to destructive migration".
I changed the content of the database and removed some columns from the database file.
Then I installed the previous version of the app (unchanged database). Then I used the application and made sure a database instance is created.
Then I installed the new version of the app (changed database). And it didn't crash and everything worked fine. Changes applied to the database.
Our app has DB version 14 and uses the android sqllite helpers. Now we are moving to use the room db and migrating all the DB stuff to room. we have defined all the migrations from 1_2, 2_3 .. to 13_14 and give all these int the build
.databaseBuilder(
app,
Database::class.java,
"my.db"
).addMigrations(arrayOf(
MIGRATION_1_2,
MIGRATION_2_3,
.....
MIGRATION_10_11,
MIGRATION_11_12,
MIGRATION_12_13,
MIGRATION_13_14
))
.build()
Is this right way of doing. If i have the non room version of the app installed with DB version 14 and i try to update it to room version of the app with same db version 14, I am getting the error :
java.lang.IllegalStateException: Room cannot verify the data
integrity. Looks like you've changed schema but forgot to update the
version number. You can simply fix this by increasing the version
number.
You only need to add a migration from your existing SQLite database to a Room-managed database. This should be an empty "do nothing" migration. This is required so that Room plays nicely with your existing database.
I have an existing sqlite database on version 3. My SqliteOpenHelper manages upgrading from v1 to 3. I'd like to migrate to Room. I understand making a new Room Migration to go from my current v3 to the new Roomified v4, but where do my existing migration scripts go?
If user upgrades app from v2 of the database straight to v4 of the database, Room will handle v3 to 4, but what handles v2 to 3?
I tried porting migration scripts into Room Migration objects, but they fail to run because no json schema exists (room was used on those schemas).
I tried keeping my old SqliteOpenHelper around and using it to upgrade from 1 to 3 before building the Room database. This works first run, but subsequent runs crash the SqliteOpenHelper saying it can't downgrade the db (Room successfully upgrades to v4, but open helper only knows about v3. Using it to ensure db upgraded to v3 causes it to try and downgrade)
Generally you can move all your old migrations to Room's Migration objects, so in your case create all of : Migration(1, 2), Migration(2, 3), Migration(3, 4) migrations.
There are also a few things to know about:
migrations will be executed lazily - when the first query is
executed, not when Room instance is retrieved
if your current version is 3 you will need to create migration to version 4, even empty, as you already noticed
if you want to speed up the migration process, you can create direct Migrations like Migration(1,4)
Take a look at this example which is well described in this article and let me know if you have any more questions.
I am using Room Persistance library which android has released as a alternative for SQLite Database.
I am currently having Android app on playstore with SQLite Database and While migrating app from SQLite to Room, I am facing several errors.
First
If I create new table do I need to write migration script i.e; I need to write migration query in Room everytime I upgrade the room version?
Second
I have the DB version on playstore with version of 20 and when I upgrade it to 21. Do I need to write migration scripts from 1 to 20 and 20 to 21 or only from 20 to 21.
Because I don't know what app db version does user have (production app), it can be 10,12, 15. How will the migration scripts be?
Thank you.
Every time you add a table (or make any schema change) you need to either a) add a migration or b) call .fallbackToDestructiveMigration() ONLY IF YOU DON'T CARE ABOUT PERSISTING THE DATA. Check out https://medium.com/google-developers/understanding-migrations-with-room-f01e04b07929 for more.
You'll need to write a migration script for every database your user could be on to upgrade them to 21 (again, unless you don't care about persisting data, in which case you can use .fallbackToDestructiveMigration()). This above link should also address this question.
Hope this helps!
I'm trying to figure out the best way to handle database upgrades and versioning.
At the moment I delete the database and log users out when I do a point release, which isn't a great experience.
Can anyone recommend any tips for doing this?
Your database version is independent of your app version. If your database schema doesn't change at all, you shouldn't need to do anything to your database during an update.
When your database schema changes, you should handle database updates in onUpgrade() of your SQLiteOpenHelper. This method is called when you try to access your database and you have updated your database version, as described in the Data Storage Options documentation.
If you are using a third party library to handle your databases, it should either handle the upgrade for you or provide similar functionality.
There is no universal strategy for upgrading your database here. What you do depends completely on what your schema looked like before the upgrade and what the new schema looks like. Depending on what changed, you might create new tables or columns, delete tables or columns, update rows in the database, or move data between tables. If you have a specific question about how to migrate your data, create a new question describing the new and old schemas.
The way we do it is that we run a routine every time the app starts that calls a stored proc on the server to get SQL that upgrades the database if it is necessary. (The sql can be quite involved: dropping tables and recreates them with new structures and inserting new values). We store the version of the database in the database itself and upgrades to the new version.
We don't use the onUpgrade() call.