Что нужно сделать чтобы все работало если изменю поле с int на string в Room?

Миграция поля с int на String в Room: пошаговое руководство

Изменение типа поля с int на String в Room — это несовместимое изменение схемы БД, требующее выполнения миграции. Простое изменение аннотаций в Entity-классе приведет к крашу приложения на существующих устройствах. Вот полный алгоритм действий.

Шаг 1: Обновление Entity-класса

Сначала меняем тип поля в вашем Entity-классе:

// БЫЛО
@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val age: Int // Меняем это поле
)

// СТАЛО
@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val age: String // Новый тип - String
)

Шаг 2: Увеличение версии базы данных

В классе базы данных увеличиваем номер версии:

@Database(entities = [User::class], version = 2) // Меняем с 1 на 2
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Шаг 3: Создание и реализация миграции

Ключевой момент: необходимо создать объект миграции, который объяснит Room, как преобразовать существующую таблицу:

val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        // 1. Создаем временную таблицу с новой схемой
        database.execSQL(
            "CREATE TABLE users_new (" +
            "id INTEGER PRIMARY KEY NOT NULL, " +
            "age TEXT)" // Теперь TEXT вместо INTEGER
        )
        
        // 2. Копируем данные из старой таблицы, преобразуя int в string
        database.execSQL(
            "INSERT INTO users_new (id, age) " +
            "SELECT id, CAST(age AS TEXT) FROM users"
        )
        
        // 3. Удаляем старую таблицу
        database.execSQL("DROP TABLE users")
        
        // 4. Переименовываем новую таблицу в оригинальное имя
        database.execSQL("ALTER TABLE users_new RENAME TO users")
    }
}

Шаг 4: Регистрация миграции при создании БД

Добавляем миграцию при построении базы данных:

val appDatabase = Room.databaseBuilder(
    context.applicationContext,
    AppDatabase::class.java, 
    "app-database"
)
.addMigrations(MIGRATION_1_2) // Регистрируем миграцию
.build()

Шаг 5: Обработка обратной совместимости в DAO и коде приложения

После изменения типа поля необходимо обновить все связанные компоненты:

1. Обновление DAO-интерфейсов:

@Dao
interface UserDao {
    // Было: fun getUsersByAge(age: Int): List<User>
    fun getUsersByAge(age: String): List<User> // Теперь принимаем String
    
    @Query("SELECT * FROM users WHERE age = :ageValue")
    fun findUsersByAge(ageValue: String): List<User>
}

1. Преобразование бизнес-логики:

// Старая логика могла использовать числовые операции
// val isAdult = user.age > 18

// Новая логика с парсингом
val ageInt = user.age.toIntOrNull() ?: 0
val isAdult = ageInt > 18

Критические моменты на которые стоит обратить внимание:

• Потеря данных: При конвертации int в String обычно проблем нет, но при обратной конвертации (String в int) могут возникнуть ошибки парсинга
• Производительность: Для больших таблиц операция копирования может занять время, лучше выполнять в фоне
• Тестирование: Обязательно протестируйте миграцию на устройствах с существующей БД
• Резервное копирование: Рассмотрите возможность создания бэкапа перед миграцией
• Индексы и ограничения: Если на поле были индексы или constraints, их нужно воссоздать в новой таблице

Альтернативный подход: временное хранение обоих типов

Если нужно поддерживать обе версии данных какое-то время:

@Entity(tableName = "users")
data class User(
    @PrimaryKey val id: Int,
    val age: String,
    @ColumnInfo(defaultValue = "0")
    val ageInt: Int // Временное поле для обратной совместимости
)

Такой подход позволяет постепенно перенести логику приложения на новый формат данных.

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