Wstępne wypełnianie bazy danych sal

Czasami może być konieczne, aby aplikacja rozpoczynała działanie od bazy danych, która jest już z określonym zbiorem danych. Jest to tzw. wstępne wypełnianie bazy danych. W pokoju 2.2.0 i nowszych możesz użyć metod interfejsu API, aby wstępnie wypełnić bazę danych sal przy inicjowaniu pliku z gotowym plikiem bazy danych systemu plików.

Wstępne wypełnianie z komponentu z linkiem do aplikacji

Aby wstępnie wypełnić bazę danych sal ze wstępnie spakowanego pliku bazy danych, który znajduje się w dowolnym miejscu w katalogu assets/ aplikacji, wywołaj createFromAsset() z obiektu RoomDatabase.Builder przed wywołaniem funkcji build():

Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .build()

Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .build();

Metoda createFromAsset() akceptuje argument tekstowy zawierający znak ścieżkę względną z katalogu assets/ do gotowego pliku bazy danych.

Wypełnij wstępnie z systemu plików

Aby wstępnie wypełnić bazę danych sal ze wstępnie spakowanego pliku bazy danych, który znajduje się w dowolnym miejscu w systemie plików urządzenia oprócz katalogu assets/ aplikacji, wywołaj metodę createFromFile() z obiektu RoomDatabase.Builder przed zadzwonieniem do firmy build():

Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromFile(File("mypath"))
    .build()

Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromFile(new File("mypath"))
    .build();

Metoda createFromFile() akceptuje argument File dla funkcji gotowy plik bazy danych. Sala utworzy kopię wskazanego pliku, niż otwierać ją bezpośrednio, więc upewnij się, że aplikacja ma uprawnienia do odczytu .

Obsługa migracji obejmujących gotowe bazy danych

Gotowe pliki bazy danych mogą też zmienić sposób obsługi bazy danych sal migracji zastępczych. Zwykle po włączeniu szkodliwych migracji a pokój musi przeprowadzić migrację bez migracji. ścieżki, pokój usuwa wszystkie tabele w bazie danych i tworzy pustą bazę danych z określony schemat wersji docelowej. Jeśli jednak dodasz tag gotowy plik bazy danych o tym samym numerze co wersja docelowa – Sala próbuje wypełnić nowo odtworzoną bazę danych zawartością gotowego pliku bazy danych po przeprowadzeniu niszczycielskiej migracji.

Więcej informacji o migracji bazy danych sal znajdziesz w artykule Migracja pokoju baz danych.

W sekcjach poniżej znajdziesz kilka przykładów działania tej funkcji w praktyce.

Przykład: migracja rezerwowa z użyciem gotowej bazy danych

Załóżmy, że:

• Aplikacja definiuje bazę danych sal w wersji 3.
• Instancja bazy danych, która jest już zainstalowana na urządzeniu, ma wersję 2.
• Istnieje już gotowy plik bazy danych w wersji 3.
• Brak wdrożonej ścieżki migracji z wersji 2 do wersji 3.
• Włączono niszczycielskie migracje.

// Database class definition declaring version 3.
@Database(version = 3)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Destructive migrations are enabled and a prepackaged database
// is provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .fallbackToDestructiveMigration()
    .build()

// Database class definition declaring version 3.
@Database(version = 3)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Destructive migrations are enabled and a prepackaged database
// is provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .fallbackToDestructiveMigration()
    .build();

Oto, co dzieje się w tej sytuacji:

1. Ponieważ baza danych zdefiniowana w Twojej aplikacji znajduje się w wersji 3, a baza danych instancja jest już zainstalowana na urządzeniu, ma wersję 2, migracja jest niezbędną.
2. Nie ma wdrożonego planu migracji z wersji 2 na wersję 3, jest migracja zastępcza.
3. Ponieważ metoda kreatora fallbackToDestructiveMigration() jest migracja zastępcza jest niszcząca. Sala usuwa bazę danych która jest zainstalowana na urządzeniu.
4. Ponieważ istnieje już gotowy plik bazy danych w wersji 3, odtwarza tę bazę danych i wypełnia ją przy użyciu zawartości . Jeśli natomiast gotowy plik bazy danych znajdował się wersji 2, wówczas sala zauważy, że nie odpowiada wersji docelowej, nie będą jej używać w ramach migracji zastępczej.

Przykład: wdrożenie migracji przy użyciu gotowej bazy danych

Załóżmy, że Twoja aplikacja wdraża ścieżkę migracji z wersji 2 do wersja 3:

// Database class definition declaring version 3.
@Database(version = 3)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Migration path definition from version 2 to version 3.
val MIGRATION_2_3 = object : Migration(2, 3) {
    override fun migrate(database: SupportSQLiteDatabase) {
        ...
    }
}

// A prepackaged database is provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_2_3)
    .build()

// Database class definition declaring version 3.
@Database(version = 3)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Migration path definition from version 2 to version 3.
static final Migration MIGRATION_2_3 = new Migration(2, 3) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        ...
    }
};

// A prepackaged database is provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_2_3)
    .build();

Oto, co dzieje się w tej sytuacji:

1. Ponieważ baza danych zdefiniowana w Twojej aplikacji znajduje się w wersji 3, a baza danych jest już zainstalowana na urządzeniu w wersji 2, konieczna jest migracja.
2. Ze względu na to, że istnieje wdrożona ścieżka migracji z wersji 2 do wersji 3, Sala uruchamia zdefiniowaną metodę migrate(), aby zaktualizować bazę danych na urządzeniu do wersji 3, co pozwala zachować dane, które są już w bazie danych. Sala nie korzysta z gotowego pliku bazy danych, ponieważ korzysta z gotowych plików bazy danych tylko w przypadku migracji zastępczej.

Przykład: wieloetapowa migracja z użyciem gotowej bazy danych

Gotowe pliki baz danych mogą też wpływać na migracje, które składają się kroków. Przeanalizujmy ten przypadek:

• Aplikacja definiuje bazę danych sal w wersji 4.
• Instancja bazy danych, która jest już zainstalowana na urządzeniu, ma wersję 2.
• Istnieje już gotowy plik bazy danych w wersji 3.
• Istnieje wdrożona ścieżka migracji z wersji 3 do wersji 4, ale nie ma z wersji 2 na wersję 3.
• Włączono niszczycielskie migracje.

// Database class definition declaring version 4.
@Database(version = 4)
abstract class AppDatabase : RoomDatabase() {
    ...
}

// Migration path definition from version 3 to version 4.
val MIGRATION_3_4 = object : Migration(3, 4) {
    override fun migrate(database: SupportSQLiteDatabase) {
        ...
    }
}

// Destructive migrations are enabled and a prepackaged database is
// provided.
Room.databaseBuilder(appContext, AppDatabase::class.java, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_3_4)
    .fallbackToDestructiveMigration()
    .build()

// Database class definition declaring version 4.
@Database(version = 4)
public abstract class AppDatabase extends RoomDatabase {
    ...
}

// Migration path definition from version 3 to version 4.
static final Migration MIGRATION_3_4 = new Migration(3, 4) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        ...
    }
};

// Destructive migrations are enabled and a prepackaged database is
// provided.
Room.databaseBuilder(appContext, AppDatabase.class, "Sample.db")
    .createFromAsset("database/myapp.db")
    .addMigrations(MIGRATION_3_4)
    .fallbackToDestructiveMigration()
    .build();

Oto, co dzieje się w tej sytuacji:

1. Ponieważ baza danych zdefiniowana w Twojej aplikacji jest w wersji 4, a baza danych instancja jest już zainstalowana na urządzeniu, ma wersję 2, migracja jest niezbędną.
2. Brak wdrożonej ścieżki migracji z wersji 2 do wersji 3, jest migracja zastępcza.
3. Ponieważ metoda kreatora fallbackToDestructiveMigration() jest migracja zastępcza jest niszcząca. Sala usuwa bazę danych na urządzeniu.
4. Ponieważ istnieje już gotowy plik bazy danych w wersji 3, odtwarza tę bazę danych i wypełnia ją przy użyciu zawartości .
5. Baza danych zainstalowana na urządzeniu jest teraz w wersji 3. Ponieważ jest to nadal jest niższa niż wersja zdefiniowana w Twojej aplikacji, kolejna migracja niezbędną.
6. Ponieważ istnieje wdrożona ścieżka migracji z wersji 3 do wersji 4, Sala uruchamia zdefiniowaną metodę migrate(), aby zaktualizować bazę danych instancji na urządzeniu do wersji 4, z zachowaniem skopiowanych danych z gotowego pliku bazy danych w wersji 3.

Dodatkowe materiały

Więcej informacji o wstępnym wypełnianiu bazy danych sal znajdziesz w tych dodatkowych i zasobami Google Cloud.

Filmy

• Co nowego w pokojach (Android Dev Summit 2019)

Blogi

• Pakowanie sali: wstępne wypełnienie bazy danych tą jedną metodą