Home » Android » Android room persistent library – How to change database version

Android room persistent library – How to change database version

Posted by: admin June 15, 2020 Leave a comment

Questions:

Im not clear on how to use room after i have updated the database version.

For example, lets say i originally had the following database defined in room:

@Database(entities = {Event.class}, version = 1)
@TypeConverters(DateTypeConverter.class)
public abstract class EventDatabase extends RoomDatabase {

   public abstract EventDao eventDao();

}

and then i change the version so that it looks like this now:

@Database(entities = {Event.class}, version = 2)
@TypeConverters(DateTypeConverter.class)
public abstract class EventDatabase extends RoomDatabase {

   public abstract EventDao eventDao();

}

when i saw change the version i mean that i may have added or deleted columns in the database so its not same. my questions are the following:

do i need to maintain two databases now ? v1 and v2 ? and is there a way to copy entities easily over to v2 ? also when changing the version is it enough to simply change it from 1 to 2 or do i have to create another class called EventDatabase2 for example ?

also here is the version of room i am using:android.arch.persistence.room:runtime:1.0.0-alpha1

How to&Answers:

So lets say i have a new app version and a new database version also. I simply need to change the version = 2 like this:

@Database(entities = {Event.class}, version = 2)
@TypeConverters(DateTypeConverter.class)
public abstract class EventDatabase extends RoomDatabase {

   public abstract EventDao eventDao();

}

and then provide a migration policy like this:

Room.databaseBuilder(getApplicationContext(), MyDb.class, "database-name")
        .addMigrations(MIGRATION_1_2).build();

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`))");
    }
};

the key thing here is if a migration policy is not provided it seem the entire database is rebuilt (so your user would loose all previous data).

this is according to @commonsWare update link provided .

Answer:

My answer may be late, but it may help someone like me who has only recently found the answer to the same question.

For some reason you need to upgrade the database version but do not need to adjust the database, as simple as editing the @Dao adapter or the @Entity attribute without affecting the structure of the database.

If you upgrade the Version in the Database as below:

From:

@Database(
    entities = [ExampleClass::class],
    version = 1,
    exportSchema = false
)

To:

@Database(
    entities = [ExampleClass::class],
    version = 2,
    exportSchema = false
)

If you do not add anything later, the database will be refreshed as if it were deleted. To avoid deletion, you can simply add an empty Migration as follows:

private val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {

    }
}

build your database:

@Synchronized
private fun buildDatabase(context: Context, databaseName: String): AppDatabase {
    return Room.databaseBuilder(
        context.applicationContext,
        AppDatabase::class.java,
        databaseName
    )
        .addMigrations(MIGRATION_1_2)
        .allowMainThreadQueries()
        .fallbackToDestructiveMigration()
        .build()
}

Database data will not be affected

Answer:

Another option:
You can update the database version number after a modification in your DB schema, and at the same time you can use fallbackToDestructiveMigration() method in the construction of your database object if you don’t want to provide a migration plan and just apply the changes you want, although it’s always recommended to provide a migration trace:

@Provides
@Singleton
fun provideCryptocurrenciesDatabase(app: Application): Database = Room.databaseBuilder(app,
  Database::class.java, "my_db").fallbackToDestructiveMigration().build()