Status Update
Comments
da...@google.com <da...@google.com> #2
lu...@gmail.com <lu...@gmail.com> #3
It is actually a known bug in Qualcomm code, specifically, it's due to the misuse of TEE.
da...@google.com <da...@google.com> #4
lu...@gmail.com <lu...@gmail.com> #5
I still have this problem.
Smartphone Oneplus 8 IN2013
Version: Android 11
Build number: OxygenOS 11.0.11.11.IN21BA
I don't have vowifi on networks that have a DNS resolver that is on the same subnet but is not the gateway.
When I do a network scan, I get the same behaviour...
lu...@gmail.com <lu...@gmail.com> #6
Hello, any news on this issue?
By the mean time I wanted to know how fine it is to create a new manual migration to fix this issue. I had something like this in mind:
internal val MIGRATION_5_6 = object : Migration(5, 6) {
override fun migrate(database: SupportSQLiteDatabase) {
try {
database.execSQL("SELECT `id` FROM `user`")
} catch (exception: Exception) {
database.execSQL("DROP TABLE `user`")
database.execSQL("CREATE TABLE IF NOT EXISTS `user` (`id` TEXT NOT NULL, `name` TEXT NOT NULL, `email` TEXT NOT NULL, `access_token` TEXT NOT NULL, `refresh_token` TEXT NOT NULL, PRIMARY KEY(`id`))")
}
}
}
I'm just wondering if inside override fun migrate(database: SupportSQLiteDatabase)
I can query the databse with SELECT
operations without throwing exception. Will it works only for users with no id
columns or for every users?
Thanks!
li...@gmail.com <li...@gmail.com> #7
And now I took care of that.
You can try edit the code:
@Entity(tableName = "user")
data class UserEntity(
- @PrimaryKey val id: String,
val name: String,
val email: String,
@ColumnInfo(name = "access_token") val accessToken: String,
@ColumnInfo(name = "refresh_token") val refreshToken: String,
)
+ {
+ @PrimaryKey val id: String
+ }
Do noy put the @PrimaryKey Filed in (...) ,
it should be in { ... }
You can try it,I am following the progress of this issue
My English is poor(I'm Chinese), but I think you can understander it. :)
el...@google.com <el...@google.com> #8
Hi there - do you know if this exception is being thrown at a specific automigration path? (e.g. do you know if its going from version 4 to 5 but it's not happening when you go from 2 to 3)
el...@google.com <el...@google.com> #9
We will now be closing this bug as "Not Reproducible". Please respond back on this page to reopen the bug if the issue persists.
cs...@gmail.com <cs...@gmail.com> #10
In my case, current version is 3
I use mannual migration for 1 to 2, and automigration for 2 to 3.
1 to 2 works fine, but 2 to 3 fail.
but, when I use mannual migration for 2 to 3, it works fine.
It seems like to be bugs in automigration logic.
el...@google.com <el...@google.com> #11
Could you share the manual migration and the generated automigrations, as well as the schemas for all versions?
[Deleted User] <[Deleted User]> #12
cs...@gmail.com <cs...@gmail.com> #13
cs...@gmail.com <cs...@gmail.com> #14
The problem occurs when I just replace mannual migration 2_3 with automigration.
Very occasionally, generated automagration 1_2 impl contains migration query, but same error occurs, but not clear.
Schemes belows are one that generated when I did mannual migration.
I thought the operation of creating a new column was not supported by automigration, but it worked well in the new project.
In the project in question, I only upgraded version 2 to 3 and applied automigration. Room was 2.5.2... Well, I'm using the latest version.
Thank you for confirming what the issue is. This problem is giving me a headache.
el...@google.com <el...@google.com> #15
Hi! Adding new columns is supported by automigrations, and doesn't include any additional input from the user (as opposed to renaming or deleting a column or a table). Will take a look at what the issue might be with the automigration 2_3 and follow up here.
el...@google.com <el...@google.com> #16
Not sure exactly what is going on, but from looking at the schemas, it looks like the db structure did not change between version 2 and 3 based on the schemas, hence the automigration generated has an empty migrate() function. The same is the issue between version 1 and 2 by the way, there aren't any DB structure changes in the schemas. Are you sure you're doing the schema updates correctly?
For example, it looks like the table from the error recentSearchQueries
has been in the DB since version 1 (looking at the schema). And there aren't any new columns/tables being added in between versions. However, the manual migrations are referring to changes between schema versions (which are not seen on the schemas themselves)
Could you take a look at your schema at different versions to verify the structure demonstrates the changes you'd like to make in between different versions?
cs...@gmail.com <cs...@gmail.com> #17
But I'm not sure why that happened.
For testing locally, I built from a branch with version 2 logic and then switched to a branch with version 3 logic.
In version 2, exportedScheme was false, and in version 3, exportedScheme was changed to true.
That's it.
I'll look into it a little more and follow up.
Are there any good resources for understanding the inner workings of room migration?
Description
Since a recent release of my app, I have only few users (12 right now) having a migration crash when launching the app. I haven't been able to reproduce it on my side. It's an IllegalStateException that looks like this:
It seems to be a migration issue with the table named
user
, but this Entity has never been modified since it's creation. The only modification in the database recently was a new table/entity created. I have been using the AutoMigration feature from the beginning of the Room integration.Here is the UserEntity:
Also, I added
fallbackToDestructiveMigration()
when providing the room database. I though it will avoid this kind of crash and just remove and rewrite the database:I also attached the version 4 and 5 of the AutoMigration if needed to look at it.
Thanks for your help!