Миграция базы данных комнат

Question

Сколько методов мне придется использовать для переноса комнаты, если у меня есть версия db 10?

Я посмотрел в следующем примере Пример миграции Google Persistence

и я нашел Миграция varargs на основе вероятных сценариев для базы данных версии 4.

public static UsersDatabase getInstance(Context context) {
    synchronized (sLock) {
        if (INSTANCE == null) {
            INSTANCE = Room.databaseBuilder(context.getApplicationContext(),
                    UsersDatabase.class, "Sample.db") 
                    .addMigrations(MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4, MIGRATION_1_4)
                    .build(); 
        } 
        return INSTANCE;
    } 
} 

У меня такой вопрос: предположим, что я использую Room из db v1, и к тому времени, когда мое приложение достигнет db v10, сколько методов миграции мне придется написать?

В sqlite мы получаем текущую версию БД установленного приложения в onUpgrade и просто пропускаем регистр переключателей без операторов break, чтобы он удовлетворял всем обновлениям БД.

Однако я не уверен, но на самом деле, мы не можем получить текущую версию установленного приложения в базе данных в комнате, мы пишем все возможные методы для миграции.

Но это так неудобно, неуместно писать всего 45 методов, если у меня db v10!

Есть ли лучшее решение?

Answer 1

Предположим, я использую Room из db v1, и к тому времени, когда мое приложение достигнет db v10, сколько методов миграции мне придется написать?

9.

Один из подходов: 1-> 2, 2-> 3, 3-> 4, 4-> 5, 5-> 6, 6-> 7, 7-> 8, 8-> 9 и 9- > 10.

Другой подход: 1-> 10, 2-> 10, 3-> 10, ..., 9-> 10.

Я предполагаю, что первый подход более популярен, так как его легче развивать. Для каждого нового выпуска базы данных вы просто создаете один дополнительный объект.

В sqlite мы получаем текущую версию установленного приложения в БД в onUpgrade, и мы просто проваливаем случай переключения без операторов прерывания, чтобы он удовлетворял всем обновлениям БД.

Это будет примерно столько же строк кода, которые вы дадите или возьмете, чем то, что вы сделали бы в Комнате. Каждый из ваших операторов case превращается в объект Migration, который обрабатывает постепенное обновление (например, 3-> 4).

Но это так неудобно, неуместно писать всего 45 методов, если у меня db v10!

Комната знает, как «склеить» отдельные миграции, необходимые для достижения целевой версии. Итак, в первом подходе, который я описал, если приложение необходимо перенести с 3 на 10, Room может использовать 3-> 4, 4-> 5, 5-> 6, ..., 9-> 10, чтобы получить есть.

Answer 2

Запись миграций в v10 с версий 1 до 9.

public static UsersDatabase getInstance(Context context) {
synchronized (sLock) {
    if (INSTANCE == null) {
        INSTANCE = Room.databaseBuilder(context.getApplicationContext(),
                UsersDatabase.class, "Sample.db") 
                .addMigrations(MIGRATION_1_10, MIGRATION_2_10, MIGRATION_3_10, MIGRATION_4_10, .......)
                .build(); 
    } 
    return INSTANCE;
} 
} 

Когда вы знаете свою схему БД, вы можете перейти непосредственно с v1 на v10, с v2 на v10 и так далее.