Android ROOM：保留数据更新表列与字段值的高效实现方案

Hey there! I totally get the frustration of dealing with messy, repetitive Room migrations—especially when you're mostly just updating existing data (like filling vid_file_path or tweaking child_exercise_name) instead of changing the database schema. Let’s walk through some practical, clean solutions to streamline this:

If your app targets Android API 33+ and uses Room 2.4.0 or higher, AutoMigration can handle most schema changes automatically (like adding columns, modifying compatible field types) without writing full Migration classes. This cuts down on boilerplate for structure updates.

For data-specific changes (like updating names or filling null vid_file_path values), pair AutoMigration with a RoomDatabase.Callback to run post-migration data fixes. Example setup:

// Define your database with AutoMigration
@Database(
    entities = [ChildExercises::class],
    version = 2,
    autoMigrations = [AutoMigration(from = 1, to = 2)]
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun childExercisesDao(): ChildExercisesDao
}

// Add a callback to handle data updates after migration
val dbCallback = object : RoomDatabase.Callback() {
    override fun onCreate(db: SupportSQLiteDatabase) {
        super.onCreate(db)
        // Initial population logic here if needed
    }

    override fun onOpen(db: SupportSQLiteDatabase) {
        super.onOpen(db)
        CoroutineScope(Dispatchers.IO).launch {
            val appDb = AppDatabase.getInstance(context)
            // Run data updates: fill vid paths and fix names
            appDb.childExercisesDao().updateExerciseName(1, "Updated Jumping Jacks")
            appDb.childExercisesDao().updateVidPath(1, "/assets/videos/jumping_jacks.mp4")
        }
    }
}

// Build the database with callback
Room.databaseBuilder(context, AppDatabase::class.java, "app_db")
    .addCallback(dbCallback)
    .build()

For schema changes that can’t use AutoMigration, bundle all migrations into a single helper class to keep your code organized. This avoids scattering Migration logic across your codebase:

object MigrationManager {
    val ALL_MIGRATIONS = arrayOf(
        buildMigration(1, 2) { db ->
            // Schema change example (if needed)
            // db.execSQL("ALTER TABLE child_exercises_table ADD COLUMN last_updated TIMESTAMP")
            
            // Data updates
            db.execSQL("""
                UPDATE child_exercises_table 
                SET child_exercise_name = 'Modified Squat', vid_file_path = '/videos/squat.mp4'
                WHERE childExercises_id = 2 AND vid_file_path IS NULL
            """)
        },
        buildMigration(2, 3) { db ->
            // Next set of schema/data changes
        }
    )

    private fun buildMigration(from: Int, to: Int, action: (SupportSQLiteDatabase) -> Unit): Migration {
        return object : Migration(from, to) {
            override fun migrate(db: SupportSQLiteDatabase) = action(db)
        }
    }
}

// Use the migrations in your database builder
Room.databaseBuilder(context, AppDatabase::class.java, "app_db")
    .addMigrations(*MigrationManager.ALL_MIGRATIONS)
    .build()

If you’re frequently updating data (not schema), add a dedicated table to track the version of your seed data. This lets you run incremental data updates without bumping the database schema version every time:

Step 1: Add a data version entity and DAO #

@Entity(tableName = "data_version")
data class DataVersion(
    @PrimaryKey val id: Int = 1,
    val currentVersion: Int = 0
)

@Dao
interface DataVersionDao {
    @Query("SELECT currentVersion FROM data_version WHERE id = 1")
    suspend fun getCurrentDataVersion(): Int

    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun updateDataVersion(version: DataVersion)
}

Step 2: Run data updates based on version #

val dbCallback = object : RoomDatabase.Callback() {
    override fun onOpen(db: SupportSQLiteDatabase) {
        super.onOpen(db)
        CoroutineScope(Dispatchers.IO).launch {
            val appDb = AppDatabase.getInstance(context)
            val currentDataVersion = appDb.dataVersionDao().getCurrentDataVersion()

            if (currentDataVersion < 1) {
                // First round of data fixes
                appDb.childExercisesDao().bulkUpdateNamesAndVidPaths(listOf(
                    Pair(3, "Updated Push-Up", "/videos/pushup.mp4"),
                    Pair(4, "Updated Lunges", "/videos/lunges.mp4")
                ))
                appDb.dataVersionDao().updateDataVersion(DataVersion(currentVersion = 1))
            }

            if (currentDataVersion < 2) {
                // Second round of data fixes
                appDb.childExercisesDao().fillNullVidPaths("/videos/default.mp4")
                appDb.dataVersionDao().updateDataVersion(DataVersion(currentVersion = 2))
            }
        }
    }
}

Store your latest complete seed data (e.g., a JSON file in assets) and merge it with existing data on app launch. This works well if you need to refresh multiple entries at once without writing individual SQL statements:

// Read seed data from assets
fun loadUpdatedExercises(context: Context): List<ChildExercises> {
    val jsonString = context.assets.open("updated_child_exercises.json")
        .bufferedReader()
        .use { it.readText() }
    return Gson().fromJson(jsonString, object : TypeToken<List<ChildExercises>>() {}.type)
}

// Merge data in your callback
val dbCallback = object : RoomDatabase.Callback() {
    override fun onOpen(db: SupportSQLiteDatabase) {
        super.onOpen(db)
        CoroutineScope(Dispatchers.IO).launch {
            val appDb = AppDatabase.getInstance(context)
            val updatedExercises = loadUpdatedExercises(context)
            
            // Only update name and vid_file_path, preserve other data
            updatedExercises.forEach { exercise ->
                appDb.childExercisesDao().updateExercise(
                    exercise.childExercises_id,
                    exercise.child_exercise_name,
                    exercise.vid_file_path
                )
            }
        }
    }
}

Pick the approach that fits your workflow best: AutoMigration for schema changes, centralized migrations for structured updates, data version tracking for frequent data tweaks, or seed data merging for bulk refreshes.

内容的提问来源于stack exchange，提问作者Josh Brett