Status Update
Comments
ma...@caringvillage.com <ma...@caringvillage.com> #2
So, the view is something we added recently. It appears that
- removing the view entirely, the destructive migration works. But it doesn't actually remove the view.
- adding the view back in, the destructive migration fails with the same message.
It appears that the destructive migration is not dropping the view, but it does try to create it again, which is what blows up.
I was able to work around this by adding a RoomCallback
and overriding the onDestructiveMigration callback to manually delete the view:
override fun onDestructiveMigration(connection: SQLiteConnection) {
super.onDestructiveMigration(connection)
connection.execSQL("DROP VIEW IF EXISTS calendar_items_view")
}
This is a pretty big potential footgun for anyone using views with destructive migrations!
da...@google.com <da...@google.com> #3
This sounds like a bug, with destructive migrations turned ON, views should also be recreated and it seems they are not being dropped before being created again leading to the 'already exists' issue.
da...@google.com <da...@google.com>
ap...@google.com <ap...@google.com> #4
Project: platform/frameworks/support
Branch: androidx-main
Author: Daniel Santiago Rivera <
Link:
Drop views during destructive migrations.
Expand for full commit details
Drop views during destructive migrations.
When 'allowDestructiveMigrationForAllTables' is turned ON (default in KMP) it should also drop all views so they can be recreated, this follows the same behaviour as when 'allowDestructiveMigrationForAllTables' is OFF and the RoomDatabase defined views are dropped.
Bug: 381518941
Test: MigrationTest
Change-Id: Iaf27b30b859b3a21f71d252e5c223dfd28365da0
Files:
- M
room/integration-tests/testapp/src/androidTest/java/androidx/room/integration/testapp/migration/MigrationTest.java
- M
room/room-runtime/src/androidMain/kotlin/androidx/room/RoomOpenHelper.android.kt
- M
room/room-runtime/src/commonMain/kotlin/androidx/room/RoomConnectionManager.kt
Hash: 0a3e83009a1f514c7d43870110b63eebb0371efc
Date: Wed Dec 04 10:53:59 2024
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #5
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.room:room-runtime:2.7.0-alpha12
androidx.room:room-runtime-android:2.7.0-alpha12
androidx.room:room-runtime-iosarm64:2.7.0-alpha12
androidx.room:room-runtime-iossimulatorarm64:2.7.0-alpha12
androidx.room:room-runtime-iosx64:2.7.0-alpha12
androidx.room:room-runtime-jvm:2.7.0-alpha12
androidx.room:room-runtime-linuxarm64:2.7.0-alpha12
androidx.room:room-runtime-linuxx64:2.7.0-alpha12
androidx.room:room-runtime-macosarm64:2.7.0-alpha12
androidx.room:room-runtime-macosx64:2.7.0-alpha12
Description
I'm using:
My databases are configured with:
When a destructive migration occurs we're getting an error on Android (and I believe we're getting a similar error on iOS, but am awaiting confirmation on that).
I pulled the db from device explorer, and it looks like the "destructive" part of the migration never completed? All the tables and views are is still present - but it's all in the .wal file (first time I just pulled the .db file, and it was empty).
Clearing storage, or uninstall+reinstall resolves the issue, but that's less than ideal, and as soon as the db version is bumped again, even if no other changes are made to the code, it happens again.
It's odd that this appears to have just popped up recently, after a couple of minor changes, after appearing to have been working fine for the last ~15 or so destructive migrations.