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