As you add and change features in your app, you need to modify your entity classes to reflect these changes. When a user updates to the latest version of your app, you don't want them to lose all of their existing data, especially if you can't recover the data from a remote server.
The Room persistence library allows
you to write
Migration
classes to preserve user data in this manner. Each
Migration
class specifies a startVersion
and endVersion
. At runtime, Room runs each
Migration
class's
migrate()
method, using the correct order to migrate the database to a later version.
Kotlin
val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(database: SupportSQLiteDatabase) { database.execSQL("CREATE TABLE `Fruit` (`id` INTEGER, `name` TEXT, " + "PRIMARY KEY(`id`))") } } val MIGRATION_2_3 = object : Migration(2, 3) { override fun migrate(database: SupportSQLiteDatabase) { database.execSQL("ALTER TABLE Book ADD COLUMN pub_year INTEGER") } } Room.databaseBuilder(applicationContext, MyDb::class.java, "database-name") .addMigrations(MIGRATION_1_2, MIGRATION_2_3).build()
Java
static final Migration MIGRATION_1_2 = new Migration(1, 2) { @Override public void migrate(SupportSQLiteDatabase database) { database.execSQL("CREATE TABLE `Fruit` (`id` INTEGER, " + "`name` TEXT, PRIMARY KEY(`id`))"); } }; static final Migration MIGRATION_2_3 = new Migration(2, 3) { @Override public void migrate(SupportSQLiteDatabase database) { database.execSQL("ALTER TABLE Book " + " ADD COLUMN pub_year INTEGER"); } }; Room.databaseBuilder(getApplicationContext(), MyDb.class, "database-name") .addMigrations(MIGRATION_1_2, MIGRATION_2_3).build();
Caution: To keep your migration logic functioning as expected, use full queries instead of referencing constants that represent the queries.
After the migration process finishes, Room validates the schema to ensure that the migration occurred correctly. If Room finds a problem, it throws an exception that contains the mismatched information.
Test migrations
Migrations aren't trivial to write, and failure to write them properly could cause a crash loop in your app. To preserve your app's stability, you should test your migrations beforehand. Room provides a testing Maven artifact to assist with this testing process. However, for this artifact to work, you need to export your database's schema.
Export schemas
Upon compilation, Room exports your database's schema information into a JSON
file. To export the schema, set the room.schemaLocation
annotation processor
property in your build.gradle
file, as shown in the following code snippet:
build.gradle
android { ... defaultConfig { ... javaCompileOptions { annotationProcessorOptions { arguments = ["room.schemaLocation": "$projectDir/schemas".toString()] } } } }
You should store the exported JSON files—which represent your database's schema history—in your version control system, as it allows Room to create older versions of your database for testing purposes.
To test these migrations, add the android.arch.persistence.room:testing Maven artifact from Room into your test dependencies, and add the schema location as an asset folder, as shown in the following code snippet:
build.gradle
android { ... sourceSets { androidTest.assets.srcDirs += files("$projectDir/schemas".toString()) } }
The testing package provides a
MigrationTestHelper
class, which can read these schema files.
It also implements the JUnit4
TestRule
interface, so it can manage created databases.
A sample migration test appears in the following code snippet:
Kotlin
@RunWith(AndroidJUnit4::class) class MigrationTest { private val TEST_DB = "migration-test" @Rule val helper: MigrationTestHelper = MigrationTestHelper( InstrumentationRegistry.getInstrumentation(), MigrationDb::class.java.canonicalName, FrameworkSQLiteOpenHelperFactory() ) @Test @Throws(IOException::class) fun migrate1To2() { var db = helper.createDatabase(TEST_DB, 1).apply { // db has schema version 1. insert some data using SQL queries. // You cannot use DAO classes because they expect the latest schema. execSQL(...) // Prepare for the next version. close() } // Re-open the database with version 2 and provide // MIGRATION_1_2 as the migration process. db = helper.runMigrationsAndValidate(TEST_DB, 2, true, MIGRATION_1_2) // MigrationTestHelper automatically verifies the schema changes, // but you need to validate that the data was migrated properly. } }
Java
@RunWith(AndroidJUnit4.class) public class MigrationTest { private static final String TEST_DB = "migration-test"; @Rule public MigrationTestHelper helper; public MigrationTest() { helper = new MigrationTestHelper(InstrumentationRegistry.getInstrumentation(), MigrationDb.class.getCanonicalName(), new FrameworkSQLiteOpenHelperFactory()); } @Test public void migrate1To2() throws IOException { SupportSQLiteDatabase db = helper.createDatabase(TEST_DB, 1); // db has schema version 1. insert some data using SQL queries. // You cannot use DAO classes because they expect the latest schema. db.execSQL(...); // Prepare for the next version. db.close(); // Re-open the database with version 2 and provide // MIGRATION_1_2 as the migration process. db = helper.runMigrationsAndValidate(TEST_DB, 2, true, MIGRATION_1_2); // MigrationTestHelper automatically verifies the schema changes, // but you need to validate that the data was migrated properly. } }
Test All Migrations
The above example showed how to test an incremental migration, from one version to another. But it is recommended to have a test that goes through all your migrations. This type of test is useful for catching any discrespancy created by a database that went through the migrations path vs a recently created one.
An example of an all migrations test is shown in the followning code snippet:
Kotlin
@RunWith(AndroidJUnit4::class) class MigrationTest { private val TEST_DB = "migration-test" // Array of all migrations private val ALL_MIGRATIONS = arrayOf( MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4) @Rule val helper: MigrationTestHelper = MigrationTestHelper( InstrumentationRegistry.getInstrumentation(), AppDatabase::class.java.canonicalName, FrameworkSQLiteOpenHelperFactory() ) @Test @Throws(IOException::class) fun migrateAll() { // Create earliest version of the database. helper.createDatabase(TEST_DB, 1).apply { close() } // Open latest version of the database. Room will validate the schema // once all migrations execute. Room.databaseBuilder( InstrumentationRegistry.getInstrumentation().getTargetContext(), AppDatabase.class, TEST_DB ).addMigrations(*ALL_MIGRATIONS).build().apply { getOpenHelper().getWritableDatabase() close() } } }
Java
@RunWith(AndroidJUnit4.class) public class MigrationTest { private static final String TEST_DB = "migration-test"; @Rule public MigrationTestHelper helper; public MigrationTest() { helper = new MigrationTestHelper(InstrumentationRegistry.getInstrumentation(), AppDatabase.class.getCanonicalName(), new FrameworkSQLiteOpenHelperFactory()); } @Test public void migrateAll() throws IOException { // Create earliest version of the database. SupportSQLiteDatabase db = helper.createDatabase(TEST_DB, 1); db.close(); // Open latest version of the database. Room will validate the schema // once all migrations execute. AppDatabase appDb = Room.databaseBuilder( InstrumentationRegistry.getInstrumentation().getTargetContext(), AppDatabase.class, TEST_DB) .addMigrations(ALL_MIGRATIONS).build() appDb.getOpenHelper().getWritableDatabase(); appDb.close(); } // Array of all migrations private static final Migration[] ALL_MIGRATIONS = new Migration[]{ MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4}; }
Gracefully handle missing migration paths
After updating your database's schemas, it's possible that some on-device
databases could still use an older schema version. If Room cannot find a
migration rule for upgrading that device's database from the older version to
the current version, an
IllegalStateException
occurs.
To prevent the app from crashing when this situation occurs, call the
fallbackToDestructiveMigration()
builder method when creating the database:
Kotlin
Room.databaseBuilder(applicationContext, MyDb::class.java, "database-name") .fallbackToDestructiveMigration() .build()
Java
Room.databaseBuilder(getApplicationContext(), MyDb.class, "database-name") .fallbackToDestructiveMigration() .build();
By including this clause in your app's database-building logic, you tell Room to destructively recreate your app's database tables in cases where a migration path between schema versions is missing.
The destructive recreation fallback logic includes several additional options:
- If errors occur in specific versions of your schema history that you cannot
solve with migration paths, use
fallbackToDestructiveMigrationFrom()
. This method indicates that you'd like Room to use the fallback logic only in cases where the database attempts to migrate from one of those problematic versions. - To perform a destructive recreation only when attempting a schema downgrade,
use
fallbackToDestructiveMigrationOnDowngrade()
instead.
Handling column default value when upgrading to Room 2.2.0
Room 2.2.0 added support for defining a column default value via
@ColumnInfo(defaultValue = "...")
. A column's default value is an important
part of the database schema and your entity, it is validated by Room during a
migration. If your database had been previously created by a version of Room
older than 2.2.0 then it is possible that you might need to provide a migration
for previously added default values unknown to Room.
For example, in a version 1 of a database, there is a Song
entity declared
as such:
Song Entity, DB Version 1, Room 2.1.0
Kotlin
@Entity data class Song( @PrimaryKey val id: Long, val title: String )
Java
@Entity public class Song { @PrimaryKey final long id; final String title; }
NOT NULL
column is added:
Song Entity, DB Version 2, Room 2.1.0
Kotlin
@Entity data class Song( @PrimaryKey val id: Long, val title: String, val tag: String // added in version 2 )
Java
@Entity public class Song { @PrimaryKey final long id; final String title; @NonNull final String tag; // added in version 2 }
Migration from 1 to 2, Room 2.1.0
Kotlin
val MIGRATION_1_2 = object : Migration(1, 2) { override fun migrate(database: SupportSQLiteDatabase) { database.execSQL( "ALTER TABLE Song ADD COLUMN tag TEXT NOT NULL DEFAULT ''") } }
Java
static final Migration MIGRATION_1_2 = new Migration(1, 2) { @Override public void migrate(SupportSQLiteDatabase database) { database.execSQL( "ALTER TABLE Song ADD COLUMN tag TEXT NOT NULL DEFAULT ''"); } };
@ColumnInfo
is
added to the same column. By using ALTER TABLE
, the entity Song
is changed
to not only contain the new column tag
, but also to contain a default value.
However, versions of Room previous to 2.2.0 are unaware of such changes,
resulting in a schema mismatch between a user of the application that had a
fresh install versus a user who migrated from version 1 to 2. Specifically, a
newly created database at version 2 would not contain the default value.
For such situtation, then, a migration has to be provided so that the database schema is consistent across users of the application, since Room 2.2.0 will now validate default values once they are defined in the entity class. The type of migration required involves:
- Declaring the default value in the entity class using
@ColumnInfo
. - Increasing the database version by one.
- Providing a migration that implements the drop & re-create strategy that allows adding a default value to an already created column.
The follwing code snippet shows an example migration implementation that drops
and re-creates the Song
table:
Migration from 2 to 3, Room 2.2.0
Kotlin
val MIGRATION_2_3 = object : Migration(2, 3) { override fun migrate(database: SupportSQLiteDatabase) { database.execSQL(""" CREATE TABLE new_Song ( id INTEGER PRIMARY KEY NOT NULL, name TEXT, tag TEXT NOT NULL DEFAULT '' ) """.trimIndent()) database.execSQL(""" INSERT INTO new_Song (id, name, tag) SELECT id, name, tag FROM Song """.trimIndent()) database.execSQL("DROP TABLE Song") database.execSQL("ALTER TABLE new_Song RENAME TO Song") } }
Java
static final Migration MIGRATION_2_3 = new Migration(2, 3) { @Override public void migrate(SupportSQLiteDatabase database) { database.execSQL("CREATE TABLE new_Song (" + "id INTEGER PRIMARY KEY NOT NULL," + "name TEXT," + "tag TEXT NOT NULL DEFAULT '')"); database.execSQL("INSERT INTO new_Song (id, name, tag) " + "SELECT id, name, tag FROM Song"); database.execSQL("DROP TABLE Song"); database.execSQL("ALTER TABLE new_Song RENAME TO Song"); } };