Status Update
Comments
el...@google.com <el...@google.com>
ap...@google.com <ap...@google.com> #2
In the title I was meant to write 1 new column, not 2 new columns.
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #3
I noticed something, this is the 2.json schema file that is being generated after the above mentioned changes are completed
{
"tableName": "SubMain",
"createSql": "CREATE TABLE IF NOT EXISTS `${TABLE_NAME}` (`id` TEXT NOT NULL, `subId` TEXT, `sideId` INTEGER, `newColumn` INTEGER NOT NULL DEFAULT 0, PRIMARY KEY(`id`), FOREIGN KEY(`subId`) REFERENCES `Main`(`id`) ON UPDATE NO ACTION ON DELETE CASCADE , FOREIGN KEY(`sideId`) REFERENCES `Side`(`id`) ON UPDATE NO ACTION ON DELETE NO ACTION )",
"fields": [
{
"fieldPath": "id",
"columnName": "id",
"affinity": "TEXT",
"notNull": true
},
{
"fieldPath": "subId",
"columnName": "subId",
"affinity": "TEXT",
"notNull": false
},
{
"fieldPath": "sideId",
"columnName": "sideId",
"affinity": "INTEGER",
"notNull": false
},
{
"fieldPath": "text",
"columnName": "text",
"affinity": "TEXT",
"notNull": false
},
{
"fieldPath": "newColumn", <--- should this be created right now?
"columnName": "newColumn",
"affinity": "INTEGER",
"notNull": true,
"defaultValue": "0"
},
],
"primaryKey": {
"columnNames": [
"id"
],
"autoGenerate": false
},
"indices": [
{
"name": "index_SubMain_subId",
"unique": false,
"columnNames": [
"subId"
],
"createSql": "CREATE INDEX IF NOT EXISTS `index_SubMain_subId` ON `${TABLE_NAME}` (`subId`)"
},
{
"name": "index_SubMain_sideId",
"unique": false,
"columnNames": [
"sideId"
],
"createSql": "CREATE INDEX IF NOT EXISTS `index_SubMain_sideId` ON `${TABLE_NAME}` (`sideId`)"
}
],
"foreignKeys": [
{
"table": "Main",
"onDelete": "CASCADE",
"onUpdate": "NO ACTION",
"columns": [
"subId"
],
"referencedColumns": [
"id"
]
},
{
"table": "Side",
"onDelete": "NO ACTION",
"onUpdate": "NO ACTION",
"columns": [
"sideId"
],
"referencedColumns": [
"id"
]
}
]
}
as you can see the field entry for the newColumn is already present, but in the previous tests I conducted before, this field would never be added at this stage (?) in order for the migration to be successful.
So I checked the Database_AutoMigration_1_2_Impl
file that is being generated by the auto migration, and I noticed that there is no entry there for adding the new columnn, when I expected to see something like this instead:
database.execSQL("ALTER TABLE 'SubMain' ADD COLUMN 'newColumn' INTEGER NOT NULL DEFAULT 0");
But yet it isn't there.
The only difference I can think of between this failing migration and the previous successful ones I did is this SubMainEntity
is written in a kotlin file, unlike the successful one I did some testing with before, which was written in a .java
file.
This does not seem right? Should the file type of an entity be enough to screw up the auto migration logic?
Description
Component used: room-runtime Version used: 2.5.1 Devices/Android versions reproduced on: N/A
After upgrading a project from Room 2.4.2 to 2.5.1, I noticed a new compilation failure when setting a minimal repro project where the first and second commits compare room 2.4.2 and 2.5.1. My theory is below.
QueryCallback
on our Room database. Since this upgrade moved us to a Room version written in Kotlin for the first time, I have a theory about the cause. I've also added aWe had been using a lambda for our callback, along the lines of:
This worked, presumably, because the compiler performed a single-abstract-method (SAM) conversion and treated the lambda expression as an implementation of
QueryCallback.onQuery
.Following the Room upgrade to Kotlin for its own code, I believe this conversion no longer occurs. Kotlin supports SAM conversions for Kotlin interfaces , but they must be declared as .
fun interface Foo
rather than justinterface Foo
. As of 2.5.2,QueryCallback
is just aninterface
This isn't blocking, strictly. We can instead construct an object implementing
QueryCallback
in place of the lambda:But in addition to being more verbose, I found I had to add a
-Xjvm-default=enable
compiler flag to our project so that the interface implementation would compile. Ideally we'd be able to continue relying on SAM conversion and write a lambda instead.