Esegui la migrazione del database delle stanze virtuali

Man mano che aggiungi e modifichi le funzionalità nella tua app, devi modificare le classi di entità Room e le tabelle di database sottostanti in modo che riflettano queste modifiche. È importante mantenere i dati utente già presenti nel database on-device quando un aggiornamento dell'app modifica lo schema del database.

Room supporta sia le opzioni automatiche sia quelle manuali per la migrazione incrementale. Le migrazioni automatiche funzionano per la maggior parte delle modifiche di schema di base, ma potrebbe essere necessario definire manualmente i percorsi di migrazione per modifiche più complesse.

Migrazioni automatiche

Nota: Room supporta le migrazioni automatiche nella versione 2.4.0-alpha01 e successive. Se la tua app utilizza una versione precedente di Room, devi definire le migrazioni manualmente.

Per dichiarare una migrazione automatica tra due versioni del database, aggiungi un'annotazione @AutoMigration alla proprietà autoMigrations in @Database:

Kotlin

// 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() {
  ...
}

Java

// 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 {
  ...
}

Nota: le migrazioni di Room automatiche si basano sullo schema del database generato sia per la versione precedente sia per quella nuova del database. Se exportSchema è impostato sufalse o se non hai ancora compilato il database con il nuovo numero di versione, le migrazioni automatiche non riescono.

Specifiche della migrazione automatica

Se Room rileva modifiche ambigue dello schema e non riesce a generare un piano di migrazione senza ulteriori input, genera un errore di compilazione e ti chiede di implementare un AutoMigrationSpec. Ciò si verifica più comunemente quando una migrazione prevede uno dei seguenti elementi:

• Eliminazione o ridenominazione di una tabella.
• Eliminazione o ridenominazione di una colonna.

Puoi utilizzare AutoMigrationSpec per fornire a Room le informazioni aggiuntive di cui ha bisogno per generare correttamente i percorsi di migrazione. Definisci una classe statica che implementa AutoMigrationSpec nella classe RoomDatabase e annota con una o più delle seguenti:

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

Per utilizzare l'implementazione AutoMigrationSpec per una migrazione automatica, imposta la proprietà spec nell'annotazione @AutoMigration corrispondente:

Kotlin

@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
  ...
}

Java

@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 { }
  ...
}

Se la tua app deve eseguire altri passaggi dopo il completamento della migrazione automatica, puoi implementare onPostMigrate(). Se implementi questo metodo in AutoMigrationSpec, Room lo chiama al termine della migrazione automatica.

Nota: in Kotlin, se hai più migrazioni dello stesso tipo, devi utilizzare un contenitore per più annotazioni, ad esempio @RenameTable.Entries.

Migrazioni manuali

Nei casi in cui una migrazione comporti modifiche complesse dello schema, Room potrebbe non essere in grado di generare automaticamente un percorso di migrazione appropriato. Ad esempio, se decidi di suddividere i dati di una tabella in due tabelle, Room non può dirti come eseguire questa suddivisione. In questi casi, devi definire manualmente un percorso di migrazione implementando una classe Migration.

Una classe Migration definisce esplicitamente un percorso di migrazione tra un startVersion e un endVersion sostituendo il metodo Migration.migrate(). Aggiungi le classi Migration al tuo generatore di database utilizzando il metodo addMigrations():

Kotlin

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()

Java

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();

Attenzione: per mantenere la logica di migrazione in funzione come previsto, utilizza query complete anziché fare riferimento a costanti che rappresentano le query.

Quando definisci i percorsi di migrazione, puoi utilizzare le migrazioni automatiche per alcune versioni e quelle manuali per altre. Se definisci sia una migrazione automatica sia una manuale per la stessa versione, Room utilizza la migrazione manuale.

Testa le migrazioni

Le migrazioni sono spesso complesse e una migrazione definita in modo errato può causare l'arresto anomalo della tua app. Per preservare la stabilità della tua app, testa le migrazioni. Room fornisce un room-testing artefatto Maven per supportare il processo di test sia per le migrazioni automatiche che manuali. Affinché questo elemento possa funzionare, devi prima esportare lo schema del database.

Schemi di esportazione

Room può esportare le informazioni dello schema del database in un file JSON al momento della compilazione. I file JSON esportati rappresentano la cronologia dello schema del database. Memorizza questi file nel tuo sistema di controllo della versione in modo che Room possa creare versioni precedenti del database a scopo di test e per abilitare la generazione della migrazione automatica.

Impostare la posizione dello schema utilizzando il plug-in Gradle di Room

Se utilizzi Room versione 2.6.0 o successive, puoi applicare il plug-in Gradle Room e utilizzare l'estensione room per specificare la directory dello schema.

Groovy

plugins {
  id 'androidx.room'
}

room {
  schemaDirectory "$projectDir/schemas"
}

Kotlin

plugins {
  id("androidx.room")
}

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

Se lo schema del database è diverso in base alla variante, al flavor o al tipo di compilazione, devi specificare posizioni diverse utilizzando la configurazione schemaDirectory() più volte, ciascuna con un variantMatchName come primo argomento. Ogni configurazione può corrispondere a una o più varianti in base a un semplice confronto con il nome della variante.

Assicurati che siano esaustivi e che coprano tutte le varianti. Puoi anche includere un schemaDirectory() senza un variantMatchName per gestire le varianti non corrispondenti a nessuna delle altre configurazioni. Ad esempio, in un'app con due sfumature di compilazione demo e full e due tipi di compilazione debug e release, le seguenti sono configurazioni valide:

Groovy

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"
}

Kotlin

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")
}

Impostare la posizione dello schema utilizzando l'opzione del processore di annotazioni

Se utilizzi la versione 2.5.2 o precedente di Room o se non utilizzi il plug-in Gradle Room, imposta la posizione dello schema utilizzando l'opzione di room.schemaLocation elaborazione delle annotazioni.

I file in questa directory vengono utilizzati come input e output per alcuni task Gradle. Per la correttezza e le prestazioni delle build incrementali e memorizzate nella cache, devi utilizzare CommandLineArgumentProvider di Gradle per informare Gradle di questa directory.

Innanzitutto, copia la classe RoomSchemaArgProvider mostrata di seguito nel file di compilazione Gradle del tuo modulo. Il metodo asArguments() nella classe di esempio passa room.schemaLocation=${schemaDir.path} a KSP. Se utilizzi KAPT e javac, modifica questo valore in -Aroom.schemaLocation=${schemaDir.path}.

Groovy

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()]
  }
}

Kotlin

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}")
  }
}

Poi configura le opzioni di compilazione per utilizzare RoomSchemaArgProvider con la directory dello schema specificata:

Groovy

// 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"))
        )
      }
    }
  }
}

Kotlin

// 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"))
        )
      }
    }
  }
}

Testare una singola migrazione

Prima di poter testare le migrazioni, aggiungi l'androidx.room:room-testingartifact Maven da Room alle dipendenze di test e la posizione dello schema esportato come cartella di asset:

build.gradle

Groovy

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"
}

Kotlin

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")
}

Il pacchetto di test fornisce una MigrationTestHelper classe che può leggere i file di schema esportati. Il pacchetto implementa anche l'interfaccia JUnit4 TestRule, in modo da poter gestire i database creati.

L'esempio seguente mostra un test per una singola migrazione:

Kotlin

@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.
    }
}

Java

@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.
    }
}

Testa tutte le migrazioni

Sebbene sia possibile testare una singola migrazione incrementale, ti consigliamo di includere un test che copra tutte le migrazioni definite per il database della tua app. In questo modo, puoi assicurarti che non esistano discrepanze tra un'istanza del database creata di recente e un'istanza precedente che ha seguito i percorsi di migrazione definiti.

L'esempio seguente mostra un test per tutte le migrazioni definite:

Kotlin

@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()
        }
    }
}

Java

@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};
}

Gestire in modo corretto i percorsi di migrazione mancanti

Se Room non riesce a trovare un percorso di migrazione per eseguire l'upgrade di un database esistente su un dispositivo alla versione corrente, viene visualizzato un messaggio IllegalStateException. Se è accettabile perdere i dati esistenti quando manca un percorso di migrazione, chiama il metodo del compilatore fallbackToDestructiveMigration() quando crei il database:

Kotlin

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

Java

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

Questo metodo indica a Room di ricreare in modo distruttivo le tabelle nel database della tua app quando deve eseguire una migrazione incrementale e non è definito un percorso di migrazione.

Avviso: se imposti questa opzione nel generatore di database della tua app, Room elimina definitivamente tutti i dati dalle tabelle del database dell'utente quando tenta di eseguire una migrazione e non è definito un percorso di migrazione.

Se vuoi che la funzionalità Riparti ricorra alla ricostruzione distruttiva solo in determinate situazioni, esistono alcune alternative a fallbackToDestructiveMigration():

• Se versioni specifiche della cronologia dello schema causano errori che non riesci a risolvere con i percorsi di migrazione, utilizza fallbackToDestructiveMigrationFrom(). Questo metodo indica che vuoi che Room ricorra alla ricostituzione distruttiva solo durante la migrazione da versioni specifiche.
• Se vuoi che Room ricorra alla ricostituzione distruttiva solo durante la migrazione da una versione del database successiva a una precedente, utilizza fallbackToDestructiveMigrationOnDowngrade().

Nota: in 2.2.0 e versioni successive, Room può utilizzare un file di database precompilato in alcuni casi di migrazione di riserva anziché lasciare un database vuoto. Per scoprire di più, consulta Precompilare il database Room.

Gestire i valori predefiniti delle colonne durante l'upgrade a Room 2.2.0

In Room 2.2.0 e versioni successive, puoi definire un valore predefinito per una colonna utilizzando l'annotazione @ColumnInfo(defaultValue = "..."). Nelle versioni precedenti alla 2.2.0, l'unico modo per definire un valore predefinito per una colonna è definirlo direttamente in un'istruzione SQL eseguita, che crea un valore predefinito sconosciuto a Room. Ciò significa che se un database è stato creato inizialmente da una versione di Room precedente alla 2.2.0, l'upgrade dell'app all'utilizzo di Room 2.2.0 potrebbe richiedere la definizione di un percorso di migrazione speciale per i valori predefiniti esistenti che hai definito senza utilizzare le API Room.

Ad esempio, supponiamo che la versione 1 di un database definisce un'entità Song:

Kotlin

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

Java

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

Supponiamo inoltre che la versione 2 dello stesso database aggiunga una nuova colonna NOT NULL e definisce un percorso di migrazione dalla versione 1 alla versione 2:

Kotlin

// 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 ''")
    }
}

Java

// 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 ''");
    }
};

Ciò causa una discrepanza nella tabella sottostante tra gli aggiornamenti e le nuove installazioni dell'app. Poiché il valore predefinito per la colonna tag è dichiarato solo nel percorso di migrazione dalla versione 1 alla versione 2, tutti gli utenti che installano l'app a partire dalla versione 2 non hanno il valore predefinito per tag nel proprio schema di database.

Nelle versioni di Room precedenti alla 2.2.0, questa discrepanza è innocua. Tuttavia, se in seguito l'app esegue l'upgrade per utilizzare Room 2.2.0 o versioni successive e modifica la classe dell'entità Song in modo da includere un valore predefinito per tag utilizzando l'annotazione @ColumnInfo, Room può rilevare questa discrepanza. Ciò comporta convalide dell'organizzazione in cui si verificano errori.

Per contribuire ad assicurare la coerenza dello schema di database per tutti gli utenti quando i valori predefiniti delle colonne sono dichiarati nei percorsi di migrazione precedenti, procedi nel seguente modo la prima volta che esegui l'upgrade dell'app in modo da utilizzare Room 2.2.0 o versioni successive:

1. Dichiara i valori predefiniti delle colonne nelle rispettive classi di entità utilizzando l'annotazione @ColumnInfo.
2. Aumenta il numero di versione del database di 1.
3. Definisci un percorso di migrazione alla nuova versione che implementi la strategia di eliminazione e ricostituzione per aggiungere i valori predefiniti necessari alle colonne esistenti.

Nota: se il database della tua app utilizza le migrazioni distruttive o se non esistono percorsi di migrazione che aggiungono una colonna con un valore predefinito, questa procedura non è obbligatoria.

L'esempio seguente mostra questa procedura:

Kotlin

// 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")
    }
}

Java

// 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");
    }
};