העברת מסד הנתונים של החדרים

כשמוסיפים תכונות באפליקציה ומשנים אותן, צריך לשנות את הישות לחדר והטבלאות של מסדי הנתונים הבסיסיים כדי לשקף את השינויים האלה. חשוב כדי לשמור נתוני משתמשים שכבר נמצאים במסד הנתונים במכשיר כשאפליקציה משנה את הסכימה של מסד הנתונים.

Room תומך באפשרויות אוטומטיות וידניות להעברה מצטברת. העברות אוטומטיות פועלות עבור רוב השינויים הבסיסיים בסכימה, אבל ייתכן שיהיה עליך להגדיר באופן ידני נתיבי העברה לשינויים מורכבים יותר.

העברות אוטומטיות

כדי להצהיר על העברה אוטומטית בין שתי גרסאות של מסד נתונים, צריך להוסיף @AutoMigration הערה ל autoMigrations נכס ב-@Database:

// Database class before the version update.
@Database(
  version = 1,
  entities = [User::class]
)
abstract class AppDatabase : RoomDatabase() {
  ...
}

// Database class after the version update.
@Database(
  version = 2,
  entities = [User::class],
  autoMigrations = [
    AutoMigration (from = 1, to = 2)
  ]
)
abstract class AppDatabase : RoomDatabase() {
  ...
}

// Database class before the version update.
@Database(
  version = 1,
  entities = {User.class}
)
public abstract class AppDatabase extends RoomDatabase {
  ...
}

// Database class after the version update.
@Database(
  version = 2,
  entities = {User.class},
  autoMigrations = {
    @AutoMigration (from = 1, to = 2)
  }
)
public abstract class AppDatabase extends RoomDatabase {
  ...
}

מפרטי העברה אוטומטית

אם החדר מזהה שינויים לא ברורים בסכימה והוא לא יכול ליצור תוכנית למיגרציה ללא קלט נוסף, היא גורמת לשגיאה זמן הידור (compiler) ושואלת כדי ליישם AutoMigrationSpec בדרך כלל מצב כזה מתרחש כשהעברה כוללת אחד מהמצבים הבאים:

• מחיקה או שינוי שם של טבלה.
• מחיקה או שינוי שם של עמודה.

אפשר להשתמש באפליקציית AutoMigrationSpec כדי לספק לחדר את המידע הנוסף צריך ליצור נתיבי העברה בצורה תקינה. הגדירו מחלקה סטטית מטמיעים את AutoMigrationSpec בכיתה RoomDatabase ומוסיפים לו הערות אחד או יותר מהאפשרויות הבאות:

• @DeleteTable
• @RenameTable
• @DeleteColumn
• @RenameColumn

כדי להשתמש בהטמעה של AutoMigrationSpec להעברה אוטומטית, צריך להגדיר המאפיין spec בהערה המתאימה ב-@AutoMigration:

@Database(
  version = 2,
  entities = [User::class],
  autoMigrations = [
    AutoMigration (
      from = 1,
      to = 2,
      spec = AppDatabase.MyAutoMigration::class
    )
  ]
)
abstract class AppDatabase : RoomDatabase() {
  @RenameTable(fromTableName = "User", toTableName = "AppUser")
  class MyAutoMigration : AutoMigrationSpec
  ...
}

@Database(
  version = 2,
  entities = {AppUser.class},
  autoMigrations = {
    @AutoMigration (
      from = 1,
      to = 2,
      spec = AppDatabase.MyAutoMigration.class
    )
  }
)
public abstract class AppDatabase extends RoomDatabase {
  @RenameTable(fromTableName = "User", toTableName = "AppUser")
  static class MyAutoMigration implements AutoMigrationSpec { }
  ...
}

אם האפליקציה שלך תצטרך לבצע פעולות נוספות לאחר השלמת ההעברה האוטומטית, אתה יכול ליישם onPostMigrate() אם מטמיעים את השיטה הזו ב-AutoMigrationSpec, החדר יתקשר אליה אחרי תהליך ההעברה האוטומטי מסתיים.

העברות ידניות

במקרים שבהם ההעברה כרוכה בשינויים מורכבים בסכימה, יכול להיות שהחדר לא יהיה ליצור נתיב העברה מתאים באופן אוטומטי. לדוגמה, אם אתם מחליטים לפצל את הנתונים בטבלה לשתי טבלאות, 'חדר' לא יכול לדעת איך לבצע את הפיצול הזה. במקרים כאלה, צריך לבצע את הפעולות הבאות באופן ידני להגדיר נתיב העברה באמצעות Migration.

מחלקה Migration מגדירה באופן מפורש נתיב העברה בין startVersion ו-endVersion על ידי ביטול של Migration.migrate() . הוספת הכיתות של Migration לבונה מסדי נתונים באמצעות ה addMigrations() method:

val MIGRATION_1_2 = object : Migration(1, 2) {
  override fun migrate(database: SupportSQLiteDatabase) {
    database.execSQL("CREATE TABLE `Fruit` (`id` INTEGER, `name` TEXT, " +
      "PRIMARY KEY(`id`))")
  }
}

val MIGRATION_2_3 = object : Migration(2, 3) {
  override fun migrate(database: SupportSQLiteDatabase) {
    database.execSQL("ALTER TABLE Book ADD COLUMN pub_year INTEGER")
  }
}

Room.databaseBuilder(applicationContext, MyDb::class.java, "database-name")
  .addMigrations(MIGRATION_1_2, MIGRATION_2_3).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`))");
  }
};

static final Migration MIGRATION_2_3 = new Migration(2, 3) {
  @Override
  public void migrate(SupportSQLiteDatabase database) {
    database.execSQL("ALTER TABLE Book "
      + " ADD COLUMN pub_year INTEGER");
  }
};

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

כשמגדירים את נתיבי ההעברה, אפשר להשתמש בהעברות אוטומטיות והעברות ידניות לאחרים. אם מגדירים גם תבנית עריכה אוטומטית העברה ידנית והעברה ידנית עבור אותה גרסה, אז Room משתמש ב מיגרציה.

בדיקת העברות

העברות הן לעיתים קרובות מורכבות, והעברה שמוגדרת בצורה שגויה עלולה לגרום כדי שהאפליקציה תקרוס. כדי לשמור על היציבות של האפליקציה, כדאי לבדוק את והעברות. בחדר יש ארטיפקט של Maven מהroom-testing כדי לעזור תהליך בדיקה להעברות אוטומטיות וידניות. עבור פריט המידע הזה שנוצר בתהליך הפיתוח (Artifact) כדי צריך לייצא תחילה את הסכימה של מסד הנתונים.

ייצוא סכימות

חדר יכול לייצא את פרטי הסכימה של מסד הנתונים לקובץ JSON במהלך הידור בזמן האימון. קובצי ה-JSON שתייצאו מייצגים את היסטוריית הסכימה של מסד הנתונים. חנות קבצים אלה במערכת ניהול הגרסאות שלכם כדי שחדר יוכל ליצור גרסאות נמוכות יותר של מסד הנתונים למטרות בדיקה וכדי לאפשר יצירת העברה אוטומטית.

הגדרת מיקום הסכימה באמצעות הפלאגין Room Gradle

אם אתם משתמשים בגרסה 2.6.0 ומעלה של החדר, אתם יכולים להחיל את פלאגין Room Gradle ושימוש ב- התוסף room לציון ספריית הסכימות.

plugins {
  id 'androidx.room'
}

room {
  schemaDirectory "$projectDir/schemas"
}

plugins {
  id("androidx.room")
}

room {
  schemaDirectory("$projectDir/schemas")
}

אם הסכימה של מסד הנתונים משתנה בהתאם לווריאנט, לטעם או ל-build מהסוג הזה, יש לציין מיקומים שונים באמצעות הפרמטר schemaDirectory() כמה פעמים, כשכל אחת היא variantMatchName ארגומנט. כל הגדרה יכולה להתאים לווריאנט אחד או יותר לפי תקן להשוואה לשם הווריאנט.

חשוב לוודא שכל המסמכים מפורטים ומכסים את כל הווריאציות. אפשר גם לכלול schemaDirectory() בלי variantMatchName כדי לטפל בווריאציות שלא נמצאה להן התאמה כל הגדרה אחרת. לדוגמה, באפליקציה שיש בה שני גרסאות build demo ו-full ושני סוגי build debug ו-release, אלה ההגדרות החוקיות:

room {
  // Applies to 'demoDebug' only
  schemaDirectory "demoDebug", "$projectDir/schemas/demoDebug"

  // Applies to 'demoDebug' and 'demoRelease'
  schemaDirectory "demo", "$projectDir/schemas/demo"

  // Applies to 'demoDebug' and 'fullDebug'
  schemaDirectory "debug", "$projectDir/schemas/debug"

  // Applies to variants that aren't matched by other configurations.
  schemaDirectory "$projectDir/schemas"
}

room {
  // Applies to 'demoDebug' only
  schemaDirectory("demoDebug", "$projectDir/schemas/demoDebug")

  // Applies to 'demoDebug' and 'demoRelease'
  schemaDirectory("demo", "$projectDir/schemas/demo")

  // Applies to 'demoDebug' and 'fullDebug'
  schemaDirectory("debug", "$projectDir/schemas/debug")

  // Applies to variants that aren't matched by other configurations.
  schemaDirectory("$projectDir/schemas")
}

הגדרת מיקום הסכימה באמצעות אפשרות של מעבד הערות

אם אתם משתמשים בגרסה 2.5.2 ומטה של 'חדר', או אם אתם לא משתמשים פלאגין Room Gradle, הגדרת מיקום הסכימה באמצעות room.schemaLocation לעיבוד הערות.

הקבצים בספרייה הזו משמשים כקלט וכפלט למשימות מסוימות של Gradle. כדי לבדוק את הנכונות והביצועים של גרסאות build מצטברות ושמורות במטמון, צריך להשתמש של Gradle CommandLineArgumentProvider כדי לעדכן את Gradle לגבי הספרייה הזו.

קודם כול, מעתיקים את הכיתה RoomSchemaArgProvider שמוצגת למטה לתוך המודול קובץ build של Gradle. השיטה asArguments() בכיתה לדוגמה עוברת room.schemaLocation=${schemaDir.path} עד KSP. אם אתם משתמשים ב-KAPT וב javac, אפשר לשנות את הערך הזה ל--Aroom.schemaLocation=${schemaDir.path} במקום זאת.

class RoomSchemaArgProvider implements CommandLineArgumentProvider {

  @InputDirectory
  @PathSensitive(PathSensitivity.RELATIVE)
  File schemaDir

  RoomSchemaArgProvider(File schemaDir) {
    this.schemaDir = schemaDir
  }

  @Override
  Iterable<String> asArguments() {
    // Note: If you're using KAPT and javac, change the line below to
    // return ["-Aroom.schemaLocation=${schemaDir.path}".toString()].
    return ["room.schemaLocation=${schemaDir.path}".toString()]
  }
}

class RoomSchemaArgProvider(
  @get:InputDirectory
  @get:PathSensitive(PathSensitivity.RELATIVE)
  val schemaDir: File
) : CommandLineArgumentProvider {

  override fun asArguments(): Iterable<String> {
    // Note: If you're using KAPT and javac, change the line below to
    // return listOf("-Aroom.schemaLocation=${schemaDir.path}").
    return listOf("room.schemaLocation=${schemaDir.path}")
  }
}

לאחר מכן צריך להגדיר את אפשרויות ההידור כך שישתמשו ב-RoomSchemaArgProvider עם ספריית הסכימה שצוינה:

// For KSP, configure using KSP extension:
ksp {
  arg(new RoomSchemaArgProvider(new File(projectDir, "schemas")))
}

// For javac or KAPT, configure using android DSL:
android {
  ...
  defaultConfig {
    javaCompileOptions {
      annotationProcessorOptions {
        compilerArgumentProviders(
          new RoomSchemaArgProvider(new File(projectDir, "schemas"))
        )
      }
    }
  }
}

// For KSP, configure using KSP extension:
ksp {
  arg(RoomSchemaArgProvider(File(projectDir, "schemas")))
}

// For javac or KAPT, configure using android DSL:
android {
  ...
  defaultConfig {
    javaCompileOptions {
      annotationProcessorOptions {
        compilerArgumentProviders(
          RoomSchemaArgProvider(File(projectDir, "schemas"))
        )
      }
    }
  }
}

בדיקת העברה יחידה

כדי לבדוק את ההעברות, צריך להוסיף את androidx.room:room-testing ארטיפקט של Maven מהחדר לבדיקה של יחסי התלות ומוסיפים את המיקום של הסכימה המיוצאת כתיקיית נכסים:

build.gradle

android {
    ...
    sourceSets {
        // Adds exported schema location as test app assets.
        androidTest.assets.srcDirs += files("$projectDir/schemas".toString())
    }
}

dependencies {
    ...
    androidTestImplementation "androidx.room:room-testing:2.6.1"
}

android {
    ...
    sourceSets {
        // Adds exported schema location as test app assets.
        getByName("androidTest").assets.srcDir("$projectDir/schemas")
    }
}

dependencies {
    ...
    testImplementation("androidx.room:room-testing:2.6.1")
}

חבילת הבדיקה מספקת MigrationTestHelper , שיכול לקרוא קובצי סכימה שיוצאו. החבילה גם מטמיעה את JUnit4 TestRule כדי לנהל מסדי נתונים שנוצרו.

הדוגמה הבאה ממחישה בדיקה של העברה אחת:

@RunWith(AndroidJUnit4::class)
class MigrationTest {
    private val TEST_DB = "migration-test"

    @get:Rule
    val helper: MigrationTestHelper = MigrationTestHelper(
            InstrumentationRegistry.getInstrumentation(),
            MigrationDb::class.java.canonicalName,
            FrameworkSQLiteOpenHelperFactory()
    )

    @Test
    @Throws(IOException::class)
    fun migrate1To2() {
        var db = helper.createDatabase(TEST_DB, 1).apply {
            // Database has schema version 1. Insert some data using SQL queries.
            // You can't use DAO classes because they expect the latest schema.
            execSQL(...)

            // Prepare for the next version.
            close()
        }

        // Re-open the database with version 2 and provide
        // MIGRATION_1_2 as the migration process.
        db = helper.runMigrationsAndValidate(TEST_DB, 2, true, MIGRATION_1_2)

        // MigrationTestHelper automatically verifies the schema changes,
        // but you need to validate that the data was migrated properly.
    }
}

@RunWith(AndroidJUnit4.class)
public class MigrationTest {
    private static final String TEST_DB = "migration-test";

    @Rule
    public MigrationTestHelper helper;

    public MigrationTest() {
        helper = new MigrationTestHelper(InstrumentationRegistry.getInstrumentation(),
                MigrationDb.class.getCanonicalName(),
                new FrameworkSQLiteOpenHelperFactory());
    }

    @Test
    public void migrate1To2() throws IOException {
        SupportSQLiteDatabase db = helper.createDatabase(TEST_DB, 1);

        // Database has schema version 1. Insert some data using SQL queries.
        // You can't use DAO classes because they expect the latest schema.
        db.execSQL(...);

        // Prepare for the next version.
        db.close();

        // Re-open the database with version 2 and provide
        // MIGRATION_1_2 as the migration process.
        db = helper.runMigrationsAndValidate(TEST_DB, 2, true, MIGRATION_1_2);

        // MigrationTestHelper automatically verifies the schema changes,
        // but you need to validate that the data was migrated properly.
    }
}

בדיקת כל ההעברות

למרות שאפשר לבדוק מיגרציה מצטברת אחת, מומלץ תכלול בדיקה שתכסה את כל ההעברות שהוגדרו עבור האפליקציה מסד נתונים. כך אפשר לוודא שאין אי-התאמה בין קובץ שנוצר לאחרונה במופע של מסד נתונים ובמכונה ישנה יותר שבעקבותיה התרחשה ההעברה שהוגדרה .

הדוגמה הבאה מציגה בדיקה של כל ההעברות המוגדרות:

@RunWith(AndroidJUnit4::class)
class MigrationTest {
    private val TEST_DB = "migration-test"

    // Array of all migrations.
    private val ALL_MIGRATIONS = arrayOf(
            MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4)

    @get:Rule
    val helper: MigrationTestHelper = MigrationTestHelper(
            InstrumentationRegistry.getInstrumentation(),
            AppDatabase::class.java.canonicalName,
            FrameworkSQLiteOpenHelperFactory()
    )

    @Test
    @Throws(IOException::class)
    fun migrateAll() {
        // Create earliest version of the database.
        helper.createDatabase(TEST_DB, 1).apply {
            close()
        }

        // Open latest version of the database. Room validates the schema
        // once all migrations execute.
        Room.databaseBuilder(
            InstrumentationRegistry.getInstrumentation().targetContext,
            AppDatabase::class.java,
            TEST_DB
        ).addMigrations(*ALL_MIGRATIONS).build().apply {
            openHelper.writableDatabase.close()
        }
    }
}

@RunWith(AndroidJUnit4.class)
public class MigrationTest {
    private static final String TEST_DB = "migration-test";

    @Rule
    public MigrationTestHelper helper;

    public MigrationTest() {
        helper = new MigrationTestHelper(InstrumentationRegistry.getInstrumentation(),
                AppDatabase.class.getCanonicalName(),
                new FrameworkSQLiteOpenHelperFactory());
    }

    @Test
    public void migrateAll() throws IOException {
        // Create earliest version of the database.
        SupportSQLiteDatabase db = helper.createDatabase(TEST_DB, 1);
        db.close();

        // Open latest version of the database. Room validates the schema
        // once all migrations execute.
        AppDatabase appDb = Room.databaseBuilder(
                InstrumentationRegistry.getInstrumentation().getTargetContext(),
                AppDatabase.class,
                TEST_DB)
                .addMigrations(ALL_MIGRATIONS).build();
        appDb.getOpenHelper().getWritableDatabase();
        appDb.close();
    }

    // Array of all migrations.
    private static final Migration[] ALL_MIGRATIONS = new Migration[]{
            MIGRATION_1_2, MIGRATION_2_3, MIGRATION_3_4};
}

טיפול יעיל בנתיבי העברה חסרים

אם Room לא מוצא נתיב העברה לשדרוג מסד נתונים קיים את המכשיר לגרסה הנוכחית, IllegalStateException. אם המיקום אפשר לאבד נתונים קיימים כאשר נתיב העברה חסר, ה fallbackToDestructiveMigration() כאשר יוצרים את מסד הנתונים:

Room.databaseBuilder(applicationContext, MyDb::class.java, "database-name")
        .fallbackToDestructiveMigration()
        .build()

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

השיטה הזו מנחה את Room ליצור מחדש באופן הרסני את הטבלאות באפליקציה כשצריך לבצע מיגרציה מצטברת ואין נתיב העברה מוגדר.

אם מעדיפים להשתמש ב'חדר' רק כדי לחזור וליהנות מפעילויות הרסניות מסוגים מסוימים במצבים מסוימים, יש כמה חלופות ל-fallbackToDestructiveMigration():

• אם גרסאות ספציפיות של היסטוריית הסכימות גורמות לשגיאות שאין לכם אפשרות לפתור עם נתיבי העברה, משתמשים fallbackToDestructiveMigrationFrom() במקום זאת. השיטה הזו מציינת שאתם רוצים שהחדר יחזור להיות הרסני רק כשעוברים מגרסאות ספציפיות.
• אם רוצים שחדר הרחצה יוכל לחזור וליהנות מפעילויות הרסניות רק לאחר ההעברה מגרסה גבוהה יותר של מסד נתונים לגרסה נמוכה יותר, משתמשים fallbackToDestructiveMigrationOnDowngrade() במקום זאת.

כשמשדרגים לחדר 2.2.0, צריך לטפל בערכי ברירת המחדל של העמודות

בחדר 2.2.0 ואילך אפשר להגדיר ערך ברירת מחדל לעמודה באמצעות ההערה @ColumnInfo(defaultValue = "...") בגרסאות שקודמות לגרסה 2.2.0, הדרך היחידה להגדיר ערך ברירת מחדל היא להגדיר אותה ישירות בהצהרת SQL שמופעלת, ותיצור ערך ברירת המחדל שהחדר לא מכיר. כלומר, אם מסד נתונים נוצרה במקור על ידי גרסה של 'חדר' ישנה יותר מ-2.2.0, ושדרגתי את האפליקציה שלך יכול להיות שתצטרכו לספק נתיב העברה מיוחד כדי להשתמש ב'חדר 2.2.0'. ערכי ברירת מחדל קיימים שהגדרתם בלי להשתמש בממשקי API של Room.

לדוגמה, נניח שגרסה 1 של מסד נתונים מגדירה ישות Song:

// Song entity, database version 1, Room 2.1.0.
@Entity
data class Song(
    @PrimaryKey
    val id: Long,
    val title: String
)

// Song entity, database version 1, Room 2.1.0.
@Entity
public class Song {
    @PrimaryKey
    final long id;
    final String title;
}

נניח גם שגרסה 2 של אותו מסד נתונים מוסיפה עמודת NOT NULL חדשה ומגדיר נתיב העברה מגרסה 1 לגרסה 2:

// Song entity, database version 2, Room 2.1.0.
@Entity
data class Song(
    @PrimaryKey
    val id: Long,
    val title: String,
    val tag: String // Added in version 2.
)

// Migration from 1 to 2, Room 2.1.0.
val MIGRATION_1_2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL(
            "ALTER TABLE Song ADD COLUMN tag TEXT NOT NULL DEFAULT ''")
    }
}

// Song entity, database version 2, Room 2.1.0.
@Entity
public class Song {
    @PrimaryKey
    final long id;
    final String title;
    @NonNull
    final String tag; // Added in version 2.
}


// Migration from 1 to 2, Room 2.1.0.
static final Migration MIGRATION_1_2 = new Migration(1, 2) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        database.execSQL(
            "ALTER TABLE Song ADD COLUMN tag TEXT NOT NULL DEFAULT ''");
    }
};

הדבר גורם לפערים בטבלה הבסיסית בין עדכונים לבין נתונים חדשים התקנות של האפליקציה. כי ערך ברירת המחדל של העמודה tag הוא רק מוצהר בנתיב ההעברה מגרסה 1 לגרסה 2, כל המשתמשים להתקין את האפליקציה החל מגרסה 2 לא כוללים את ערך ברירת המחדל עבור tag בסכימה של מסד הנתונים.

בגרסאות של 'חדר' שקודמות לגרסה 2.2.0, הפער הזה לא מזיק. אבל אם האפליקציה תשדרג מאוחר יותר לשימוש בחדר 2.2.0 ואילך ותשנה את הישות Song class כדי לכלול ערך ברירת מחדל עבור tag באמצעות הפונקציה הערה @ColumnInfo, חדר ואז נוכל לראות את הפער. התוצאה היא סכימה נכשלה אימותים חדשים.

כדי להבטיח שסכימת מסד הנתונים עקבית בין כל המשתמשים כאשר העמודה ערכי ברירת המחדל מוצהרים בנתיבי ההעברה הקודמים, יש לבצע את הפעולות הבאות בפעם הראשונה שמשדרגים את האפליקציה לשימוש בחדר 2.2.0 ואילך:

1. להצהיר על ערכי ברירת מחדל של עמודות במחלקות הישויות המתאימות באמצעות המאפיין הערה אחת (@ColumnInfo).
2. צריך להגדיל ב-1 את מספר הגרסה של מסד הנתונים.
3. להגדיר נתיב העברה לגרסה החדשה שמממשת את ההשקה ו יצירה מחדש של האסטרטגיה כדי להוסיף את ערכי ברירת המחדל הנדרשים לעמודות הקיימות.

הדוגמה הבאה ממחישה את התהליך הזה:

// Migration from 2 to 3, Room 2.2.0.
val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("""
                CREATE TABLE new_Song (
                    id INTEGER PRIMARY KEY NOT NULL,
                    name TEXT,
                    tag TEXT NOT NULL DEFAULT ''
                )
                """.trimIndent())
        database.execSQL("""
                INSERT INTO new_Song (id, name, tag)
                SELECT id, name, tag FROM Song
                """.trimIndent())
        database.execSQL("DROP TABLE Song")
        database.execSQL("ALTER TABLE new_Song RENAME TO Song")
    }
}

// Migration from 2 to 3, Room 2.2.0.
static final Migration MIGRATION_2_3 = new Migration(2, 3) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        database.execSQL("CREATE TABLE new_Song (" +
                "id INTEGER PRIMARY KEY NOT NULL," +
                "name TEXT," +
                "tag TEXT NOT NULL DEFAULT '')");
        database.execSQL("INSERT INTO new_Song (id, name, tag) " +
                "SELECT id, name, tag FROM Song");
        database.execSQL("DROP TABLE Song");
        database.execSQL("ALTER TABLE new_Song RENAME TO Song");
    }
};