Ta strona została przetłumaczona przez Cloud Translation API.

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

Kotlin

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

Java

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

Kotlin

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

Java

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.

Kotlin

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

Java

// 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:

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ą.
Nie ma wdrożonego planu migracji z wersji 2 na wersję 3, jest migracja zastępcza.
Ponieważ metoda kreatora fallbackToDestructiveMigration() jest migracja zastępcza jest niszcząca. Sala usuwa bazę danych która jest zainstalowana na urządzeniu.
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:

Kotlin

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

Java

// 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:

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

Kotlin

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

Java

// 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:

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ą.
Brak wdrożonej ścieżki migracji z wersji 2 do wersji 3, jest migracja zastępcza.
Ponieważ metoda kreatora fallbackToDestructiveMigration() jest migracja zastępcza jest niszcząca. Sala usuwa bazę danych na urządzeniu.
Ponieważ istnieje już gotowy plik bazy danych w wersji 3, odtwarza tę bazę danych i wypełnia ją przy użyciu zawartości .
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ą.
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ą

Wstecz

Tworzenie widoków w bazie danych

Dalej

Migracja bazy danych