Bitte stellen Sie im Builder eine Migration bereit oder rufen Sie im Builder fallbackToDestructiveMigration auf. In diesem Fall erstellt Room alle Tabellen neu

Lesezeit: 6 Minuten

Benutzeravatar von Pritish
Pritisch

Ich verwende Room With RxJava2. Ich habe eine Spalte in meiner Tabelle hinzugefügt, damit ich auf eine neue Version migriere. Ich habe meine Datenbankversion auf 2 geändert.

Es folgt mein Migrationscode

static final Migration MIGRATION_1_2 = new Migration(1, 2) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        database.execSQL("ALTER TABLE users "
        +"ADD COLUMN address String");

    }
};

AppDatabase db = Room.databaseBuilder(getApplicationContext(), AppDatabase.class, DB_NAME)
.addMigrations(MIGRATION_1_2)
.build();

Wenn Sie den vollständigen Code sehen möchten, beziehe ich mich auf dieses Beispiel auf Github, es enthält keinen Migrationscode

https://github.com/alahammad/RoomSample

Ich befolge die in der Dokumentation beschriebenen Schritte, aber meine App stürzt immer noch ab.

Fehlerprotokolle

Process: demo.karaoke.sensibol.com.roomrajava2, PID: 13655
    io.reactivex.exceptions.OnErrorNotImplementedException: A migration from 1 to 2 is necessary. Please provide a Migration in the builder or call fallbackToDestructiveMigration in the builder in which case Room will re-create all of the tables.
        at io.reactivex.internal.functions.Functions$OnErrorMissingConsumer.accept(Functions.java:704)
        at io.reactivex.internal.functions.Functions$OnErrorMissingConsumer.accept(Functions.java:701)
        at io.reactivex.internal.operators.maybe.MaybeCallbackObserver.onError(MaybeCallbackObserver.java:83)
        at io.reactivex.internal.operators.maybe.MaybeObserveOn$ObserveOnMaybeObserver.run(MaybeObserveOn.java:99)
        at io.reactivex.android.schedulers.HandlerScheduler$ScheduledRunnable.run(HandlerScheduler.java:109)
        at android.os.Handler.handleCallback(Handler.java:815)
        at android.os.Handler.dispatchMessage(Handler.java:104)
        at android.os.Looper.loop(Looper.java:194)
        at android.app.ActivityThread.main(ActivityThread.java:5643)
        at java.lang.reflect.Method.invoke(Native Method)
        at java.lang.reflect.Method.invoke(Method.java:372)
        at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:960)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:755)
     Caused by: java.lang.IllegalStateException: A migration from 1 to 2 is necessary. Please provide a Migration in the builder or call fallbackToDestructiveMigration in the builder in which case Room will re-create all of the tables.
        at android.arch.persistence.room.RoomOpenHelper.onUpgrade(RoomOpenHelper.java:82)
        at android.arch.persistence.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.onUpgrade(FrameworkSQLiteOpenHelper.java:118)
        at android.database.sqlite.SQLiteOpenHelper.getDatabaseLocked(SQLiteOpenHelper.java:256)
        at android.database.sqlite.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:163)
        at android.arch.persistence.db.framework.FrameworkSQLiteOpenHelper$OpenHelper.getWritableSupportDatabase(FrameworkSQLiteOpenHelper.java:93)
        at android.arch.persistence.db.framework.FrameworkSQLiteOpenHelper.getWritableDatabase(FrameworkSQLiteOpenHelper.java:54)
        at android.arch.persistence.room.RoomDatabase.query(RoomDatabase.java:193)
        at demo.karaoke.sensibol.com.roomrajava2.UserDao_Impl$4.call(UserDao_Impl.java:137)
        at demo.karaoke.sensibol.com.roomrajava2.UserDao_Impl$4.call(UserDao_Impl.java:135)
        at io.reactivex.internal.operators.maybe.MaybeFromCallable.subscribeActual(MaybeFromCallable.java:46)
        at io.reactivex.Maybe.subscribe(Maybe.java:3749)
        at io.reactivex.internal.operators.maybe.MaybeSubscribeOn$SubscribeTask.run(MaybeSubscribeOn.java:54)
        at io.reactivex.Scheduler$DisposeTask.run(Scheduler.java:452)
        at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
        at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
        at java.util.concurrent.FutureTask.run(FutureTask.java:237)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:152)
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:265)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
        at java.lang.Thread.run(Thread.java:818)

  • können Sie Fehlerprotokolle hinzufügen

    – Amjad Khan

    3. April 2018 um 12:25 Uhr

  • @AmjadKhan Ich habe die Fehlerprotokolle hinzugefügt, bitte schauen Sie nach

    – Pritisch

    3. April 2018 um 12:48 Uhr

  • Haben Sie Ihrer AppDatabase-Klasse die Annotation @Database(entities = {}, version = 1) hinzugefügt? Hatten Sie Version 1 auf Ihrem Telefon installiert und dann den Code mit Migration und Version = 2 aktualisiert und die Installation versucht?

    – lomza

    3. April 2018 um 18:48 Uhr

  • @lomza ja das habe ich gemacht. Für Version 1 @Database(entities = {User.class}, version = 1) habe ich die App auf meinem Telefon installiert und dann eine Spalte hinzugefügt und @Database(entities = {User.class}, version = 2) geändert und Ich habe die App erneut auf meinem Handy installiert

    – Pritisch

    4. April 2018 um 5:03 Uhr

  • Es gibt einen schönen Artikel über Migrationen – medium.com/google-developers/… Vielleicht findest du dort eine Lösung…

    – lomza

    4. April 2018 um 9:04 Uhr

Benutzeravatar von Foroogh Varmazyar
Foroogh Varmazyar

Wenn Sie keine Migrationen bereitstellen möchten und ausdrücklich möchten, dass Ihre Datenbank gelöscht wird, wenn Sie die Version aktualisieren, rufen Sie uns an fallbackToDestructiveMigration im Datenbank-Builder

database = Room.databaseBuilder(context.getApplicationContext(),
                    UsersDatabase.class, "Sample.db")
            .fallbackToDestructiveMigration()
            .build();

  • Müssen wir die db-Version aktualisieren oder so behalten, wie sie ist?

    – Kischan Solanki

    6. Dezember 2021 um 7:46 Uhr

  • Die Migration erfolgt, wenn sich Ihre Datenbank ändert, daher müssen Sie Ihre db-Version aktualisieren. das kann dir helfen medium.com/androiddevelopers/… @KishanSolanki

    – Foroogh Varmazyar

    6. Dezember 2021 um 8:45 Uhr

  • fallbackTODestructiveMigration bereinigt meine Datenbank jedes Mal, wenn eine neue erstellt wird oder wenn ich alle schließe und die App neu starte. Verwenden Sie diese vorübergehend für die Migration

    – Harikrushna Patel

    24. Februar um 13:29 Uhr


fügen Sie “.fallbackToDestructiveMigration()” vor build() hinzu,

  • …nur wenn Sie möchten, dass Ihre Benutzer alle ihre gespeicherten Daten verlieren

    – smitty1

    1. Dezember 2019 um 7:02 Uhr

  • @smitty1. Zustimmen. Ich vermute auch, dass ein Programmierer, wenn er später Migrationen hinzufügen möchte, Probleme mit Migrationen von alten Versionen haben wird.

    – CoolMind

    2. September 2021 um 8:03 Uhr


Benutzeravatar von lomza
Lomza

Ich habe Ihre App von GitHub ausgeführt und eine Beispielmigration von Version 1 zu Version 2 durchgeführt. Es stellt sich heraus, dass die SQL-Abfrage einen Fehler enthält. Es sollte sein:

static final Migration MIGRATION_1_2 = new Migration(1, 2) {
    @Override
    public void migrate(SupportSQLiteDatabase database) {
        database.execSQL("ALTER TABLE users "
        +"ADD COLUMN address TEXT");

    }
};

Zeichenfolge > TEXT

Es ist auch vorzuziehen, die Datenbankinstanz von Room zu einem Singleton zu machen und sie nur in der Repo/CacheManager-Klasse zu verwenden. Bitte überprüfen Sie das Wesentliche auf vollständige Codeänderungen – https://gist.github.com/lomza/0f311a1b1e9c896bc58dff925d65eab2

  • Danke für die Antwort. Lassen Sie mich prüfen und mich bei Ihnen melden. Es bedeutet mir wirklich viel, dass Sie sich die Zeit genommen haben, meinen Code zu überprüfen. Bin dankbar

    – Pritisch

    6. April 2018 um 17:08 Uhr


  • Auch wenn ich String statt TEXT schreibe, funktioniert es. Das Problem war in meiner Singleton-Klasse, die Sie bereitstellen gist.github.com/lomza/0f311a1b1e9c896bc58dff925d65eab2

    – Pritisch

    7. April 2018 um 5:27 Uhr

Wenn es akzeptabel ist, vorhandene Daten zu verlieren, rufen Sie die an fallbackToDestructiveMigration() Builder-Methode, wenn Sie die Datenbank erstellen

Beispiel:

db = Room.databaseBuilder(getApplicationContext(),
                    User.class, "DB_Name")
            .fallbackToDestructiveMigration()
            .build();

fügen Sie “.fallbackToDestructiveMigration()” vor build() hinzu und erhöhen Sie auch Ihre für mich festgelegte Versionsnummer. hoffe, es behebt für jemanden, der sucht. hier.

  • Room muss verbessert werden, um Migrationen über eine geeignete Migrationsfunktion ordnungsgemäß zu handhaben, anstatt diese Methode des Verkaufens von Raum als etwas zu verkaufen, das die Änderungen automatisch handhabt, wenn Sie sowieso SQL-Abfragen schreiben müssen.

    – TheRealChx101

    23. September um 14:35 Uhr

  • Room muss verbessert werden, um Migrationen über eine geeignete Migrationsfunktion ordnungsgemäß zu handhaben, anstatt diese Methode des Verkaufens von Raum als etwas zu verkaufen, das die Änderungen automatisch handhabt, wenn Sie sowieso SQL-Abfragen schreiben müssen.

    – TheRealChx101

    23. September um 14:35 Uhr

1431810cookie-checkBitte stellen Sie im Builder eine Migration bereit oder rufen Sie im Builder fallbackToDestructiveMigration auf. In diesem Fall erstellt Room alle Tabellen neu

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy