Migracja z SQLite do pokoju

Biblioteka trwałości sal ma wiele korzyści w porównaniu z używaniem SQLite bezpośrednio:

  • Weryfikacja zapytań SQL podczas kompilacji
  • Adnotacje wygodne, które minimalizują ilość powtarzalnych i podatnych na błędy powtarzalnych treści kod
  • Uproszczone ścieżki migracji bazy danych

Jeśli Twoja aplikacja używa obecnie implementacji SQLite innej niż sala, przeczytaj tę stronę , aby dowiedzieć się, jak przenieść aplikację do pokoju. Jeśli sala jest pierwsza Implementacja SQLite, której używasz w aplikacji. Więcej informacji znajdziesz w sekcji Zapisywanie danych w lokalnym w bazie danych Sala, by uzyskać podstawowe informacje o korzystaniu.

Etapy migracji

Wykonaj poniższe czynności, aby przenieść swoją implementację SQLite do pokoju. Jeśli jeśli wykorzystujesz dużą bazę danych lub złożone zapytania, możesz Wolą stopniowo przechodzić do pokoju. Zobacz Migracja przyrostowa w celu opracowania strategii stopniowej migracji.

Zaktualizuj zależności

Aby używać pokoju w aplikacji, musisz uwzględnić odpowiednie zależności w sekcji build.gradle aplikacji. Patrz sekcja Konfiguracja dla najbardziej aktualne zależności od sal.

Aktualizowanie klas modelu w encje danych

Sala używa encji danych do: reprezentują tabele w bazie danych. Każda klasa encji reprezentuje tabelę, zawiera pola reprezentujące kolumny w tej tabeli. Wykonaj te czynności, by zaktualizować istniejące klasy modelu na elementy typu Pokoje:

  1. Dodaj adnotację do klasy: @Entity, aby wskazać, że jest to Jednostka pokoju. Opcjonalnie możesz użyć parametru tableName do wskazują, że tabela wynikowa powinna mieć nazwę inną niż nazwę zajęć.
  2. Dodaj adnotację do pola klucza podstawowego przez @PrimaryKey
  3. Jeśli dowolna z kolumn w tabeli wynikowej powinna mieć nazwę różnią się od nazwy odpowiedniego pola, dodaj do niego adnotację @ColumnInfo i ustaw wartość name do prawidłową nazwę kolumny.
  4. Jeśli klasa zawiera pola, których nie chcesz zachowywać w bazie danych, dodaj do tych pól adnotacje @Ignore, aby wskazać, że sala nie powinien tworzyć dla nich kolumn w odpowiedniej tabeli.
  5. Jeśli klasa ma więcej niż jedną metodę konstruktora, wskaż, który konstruktor Aby użyć pokoju, dodaj adnotacje do wszystkich innych konstruktorów za pomocą atrybutu @Ignore.

Kotlin

@Entity(tableName = "users")
data class User(
  @PrimaryKey
  @ColumnInfo(name = "userid") val mId: String,
  @ColumnInfo(name = "username") val mUserName: String?,
  @ColumnInfo(name = "last_update") val mDate: Date?,
)

Java

@Entity(tableName = "users")
public class User {

  @PrimaryKey
  @ColumnInfo(name = "userid")
  private String mId;

  @ColumnInfo(name = "username")
  private String mUserName;

  @ColumnInfo(name = "last_update")
  private Date mDate;

  @Ignore
  public User(String userName) {
    mId = UUID.randomUUID().toString();
    mUserName = userName;
    mDate = new Date(System.currentTimeMillis());
  }

  public User(String id, String userName, Date date) {
    this.mId = id;
    this.mUserName = userName;
    this.mDate = date;
  }

}

Tworzenie DAO

Sala używa obiektów dostępu do danych (DAO) do definiowania metod dostępu do bazy danych. Postępuj zgodnie ze wskazówkami w artykule Uzyskiwanie dostępu do danych za pomocą Pokoju DAO, które zastąpią dotychczasowe zapytanie za pomocą DAO.

Tworzenie klasy bazy danych

Implementacje pokoi używają klasy bazy danych do zarządzania instancją w bazie danych. Klasa bazy danych powinna być rozszerzona RoomDatabase i odwołaj się do wszystkich zdefiniowanych przez Ciebie jednostek i agencji DAO.

Kotlin

@Database(entities = [User::class], version = 2)
@TypeConverters(DateConverter::class)
abstract class UsersDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Java

@Database(entities = {User.class}, version = 2)
@TypeConverters(DateConverter.class)
public abstract class UsersDatabase extends RoomDatabase {
  public abstract UserDao userDao();
}

Zdefiniuj ścieżkę migracji

Ponieważ zmienia się numer wersji bazy danych, musisz zdefiniować Migration obiektu wskazują ścieżkę migracji, dzięki czemu Room przechowuje istniejące dane w bazie danych. Dopóki schemat bazy danych się nie zmieni, pole może być puste implementacji.

Kotlin

val MIGRATION_1_2 = object : Migration(1, 2) {
  override fun migrate(database: SupportSQLiteDatabase) {
    // Empty implementation, because the schema isn't changing.
  }
}

Java

static final Migration MIGRATION_1_2 = new Migration(1, 2) {
  @Override
  public void migrate(SupportSQLiteDatabase database) {
    // Empty implementation, because the schema isn't changing.
  }
};

Więcej informacji o ścieżkach migracji baz danych w pokoju znajdziesz w artykule Migracja .

Zaktualizuj instancję bazy danych

Po zdefiniowaniu klasy bazy danych i ścieżki migracji możesz używać Room.databaseBuilder aby utworzyć instancję bazy danych z zastosowaną ścieżką migracji:

Kotlin

val db = Room.databaseBuilder(
          applicationContext,
          AppDatabase::class.java, "database-name"
        )
          .addMigrations(MIGRATION_1_2).build()

Java

db = Room.databaseBuilder(
          context.getApplicationContext(),
          UsersDatabase.class, "database-name"
        )
          .addMigrations(MIGRATION_1_2).build();

Testowanie implementacji

Pamiętaj, aby przetestować nową implementację pokoi:

  • Postępuj zgodnie ze wskazówkami podanymi w sekcji Testowanie migracje, aby przetestować migracji bazy danych.
  • Postępuj zgodnie ze wskazówkami podanymi w sekcji Testowanie w bazie danych w celu przetestowania DAO. .

Migracja przyrostowa

Jeśli Twoja aplikacja używa dużej, złożonej bazy danych, migracja może być niemożliwa z aplikacji do pokoju. Zamiast tego możesz opcjonalnie zaimplementować dane encje i bazę danych sal, a potem przeprowadź migrację metod zapytań. później w DAO. Aby to zrobić, zastąp niestandardowy pomocnik bazy danych klasą z SupportSQLiteOpenHelper. obiekt otrzymywany z RoomDatabase.getOpenHelper()

Dodatkowe materiały

Aby dowiedzieć się więcej o migracji z SQLite do pokoju, zapoznaj się z następującymi dodatkowymi zasoby:

Blogi