Status Update
Comments
pa...@outlook.com <pa...@outlook.com> #2
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
da...@google.com <da...@google.com>
pa...@outlook.com <pa...@outlook.com> #3
pa...@outlook.com <pa...@outlook.com> #4
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
pa...@outlook.com <pa...@outlook.com> #5
I think I found the problem, but I cannot check why it is happening because I don't know how to check the automigration logic builder, I can only confirm the result of the bug, but not the origin of it in the source code of the auto migration implementation builder.
Besides the entity I described previously, where I add a newColumn
to it, I also happened to have another entity that also has an exact same column being added to it, same name, and same type, just on a completely different entity.
It seems that when the auto migration builder logic starts reading the changes it is ignoring the newColumn
in SubMainEntity
because it already detected that another entity, let's call it FirstMainEntity
, also has a new column named newColumn
, and so when it generates the auto migration schema this is the result
class Database_AutoMigration_1_2_Impl extends Migration {
public Database_AutoMigration_1_2_Impl() {
super(1, 2);
}
@Override
public void migrate(@NonNull SupportSQLiteDatabase database) {
database.execSQL("ALTER TABLE `FirstMain` ADD COLUMN `newColumn` INTEGER NOT NULL DEFAULT 0");
}
}
However, if I rename the newColumn
in FirstMainEntity
to something different like this:
@ColumnInfo(name = "newColumnTest", defaultValue = "0")
var newColumnTest = false
And run the build, this is what the auto migration generates now:
class Database_AutoMigration_1_2_Impl extends Migration {
public Database_AutoMigration_1_2_Impl() {
super(1, 2);
}
@Override
public void migrate(@NonNull SupportSQLiteDatabase database) {
database.execSQL("ALTER TABLE `SubMain` ADD COLUMN `newColumn` INTEGER NOT NULL DEFAULT 0");
database.execSQL("ALTER TABLE `FirstMain` ADD COLUMN `newColumnTest` INTEGER NOT NULL DEFAULT 0");
}
}
And now the migration runs without an issue.
I can only assume that this is a bug in the auto migration logic, perhaps the new columns are being cached as keys, and being used per database, instead of per table, causing any subsequent table that happens to have a new column with the same @ColumnInfo(name =...
- and I have to emphasize name
here because even when I changed its variable name, or type it made no difference - to not be recognized as having a new column added, except for the first table that was detected.
da...@google.com <da...@google.com> #6
Great detective work! You are totally right in that we have a 'key' bug. Specifically we are incorrectly keeping track of 'added columns without complex changes' using the column name, but forgot to also include the table as part of the key.
See:
I'll fix this soon.
ap...@google.com <ap...@google.com> #7
Branch: androidx-main
commit bfa17ff8b0cff84789e11a7efb384ab08c4f91e6
Author: Daniel Santiago Rivera <danysantiago@google.com>
Date: Thu Sep 23 12:10:59 2021
Don't key auto-migration added columns by name.
This is not needed and causes issues when two columns of the same name are added to two to dofferent tables.
Bug: 200818663
Test: SchemaDifferTest.kt
Relnote: Fixed an issue with auto-migrations not adding new columns when another table in the same auto-migration also had a new column with the same name.
Change-Id: Ia5db52982e050714f224805d9949215b6caeff56
M room/room-compiler/src/main/kotlin/androidx/room/util/SchemaDiffer.kt
M room/room-compiler/src/main/kotlin/androidx/room/writer/AutoMigrationWriter.kt
M room/room-compiler/src/test/kotlin/androidx/room/util/SchemaDifferTest.kt
M room/room-compiler/src/test/kotlin/androidx/room/writer/AutoMigrationWriterTest.kt
da...@google.com <da...@google.com> #8
This is fixed, but sadly didn't make it into 2.4.0-alpha05, it'll be in the next release.
da...@loylap.com <da...@loylap.com> #9
I have a similar
da...@loylap.com <da...@loylap.com> #10
sorry I've commented on the wrong issue and it won't let me delete, please ignore!
Description
Component used: Room Version used: 2.4.0-alpha04 Devices/Android versions reproduced on: Android Pixel 4A
I have an entity where I only added a new column "newColumn" between database version 1 to database version 2
I have configured the database as such
And when I run the app after the new schema files have already been generated, the app crashes and this is the error snippet that shows in the console (formatted for easier reading)
When I attach a debug point to TableInfo it stops at
because the table count is different, which makes sense to be different since I have added a new column to the existing table, but for some reason the migration logic is not account for that even though it is very suggested that auto migrations should work straight away when we just add a new column to an existing table:https://developer.android.com/training/data-storage/room/migrating-db-versions
And the blog as well also discusses straight automigration logic for just adding a new column to exiting tables:https://medium.com/androiddevelopers/room-auto-migrations-d5370b0ca6eb
What am I doing wrong here, or is this a bug? I cannot find anything in the documentation to solve this for myself.