Работал ли с миграцией БД

А, ну это же классика, ёпта! С миграциями в Room работал, да. Представь, что твоя база данных — это квартира. Жил-жил, всё норм, а потом бац — женился, детей завёл, теща переехала. Места не хватает, надо перепланировку делать, стенку сносить. Вот миграция — это и есть такой ремонт на ходу, без выселения.

Когда структуру БД меняешь — таблицу новую добавил, колонку какую-нибудь last_login прикрутил, или вообще хуй с горы — старую таблицу нахуй удалил — вот тут без миграции никак. Без неё приложение обновится, откроет БД новой схемы, а она-то осталась со старой — и тут тебе пиздец, IllegalStateException прямо в ебало.

Делается через этот самый Migration объект. Главное — версии не перепутать, а то будет тебе хиросима. Смотри, как это выглядит:

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN last_login INTEGER NOT NULL DEFAULT 0")
    }
}

Room.databaseBuilder(context, AppDatabase::class.java, "app.db")
    .addMigrations(MIGRATION_1_2)
    .build()

Вот тут (1, 2) — это с какой версии на какую переходим. С первой на вторую. И внутри migrate пишешь свой SQL, который всё и порешает. В примере — просто колонку добавляем.

А теперь, чувак, самые важные моменты, где все и обосрываются, будь добр, запомни:

1. Версии — это святое. Указал (2, 3) — значит, миграция сработает ТОЛЬКО при переходе с двойки на тройку. Если у юзера была версия 1, а ты добавил миграции (1, 2) и (2, 3) — Room сам их по цепочке выполнит. Но если цепочку порвёшь — пиши пропало.
2. Исключения лови, ёб твою мать! Внутри migrate оберни свои запросы в try-catch, если что-то сложное делаешь. А то упадёт посреди процесса — и БД останется в ебенях, в полумигрированном состоянии. Доверие к тебе после этого — ноль ебать.
3. Протестировать надо, а не на глазок! Перед тем как в продакшн пулять, напиши тест, который создаёт БД старой версии, накатывает миграцию и проверяет, что всё на месте. Иначе можно получить сюрприз, от которого сам от себя охуеешь.
4. Для совсем уж диких переделок — когда не просто колонку добавить, а половину схемы перелопатить — используют временные таблицы. Создаёшь новую таблицу по новой схеме, из старой в неё данные перегоняешь, старую удаляешь, новую переименовываешь. Медленно, зато надёжно.

Короче, принцип такой: планируй миграции заранее, тестируй их как последнюю хуйню, и не делай из своей БД подобие франкенштейна с кучей костылей. И всё будет пизда рулю.