Status Update
Comments
yb...@google.com <yb...@google.com> #2
In the title I was meant to write 1 new column, not 2 new columns.
yb...@google.com <yb...@google.com>
va...@gmail.com <va...@gmail.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?
da...@gmail.com <da...@gmail.com> #4
Curious enough, if I just rename that newColumn
to anything else, the auto migration correctly creates a database SQL entry for that, like this:
database.execSQL("ALTER TABLE 'SubMain' ADD COLUMN 'newColumnRENAMED' INTEGER NOT NULL DEFAULT 0");
Which made me think if maybe the table somehow already had that column from before, so to confirm this I renamed the column to the same original name, cleaned the app, ran the build, and then I completely removed the column from the entity, but the auto migration file did not add any execSQL entry to remove that column. It's like the column is being arbitrarily completely ignored from the auto migration logic.
I tried to check the auto migration builder logic, but I cannot find it, nor do I know how to inspect such a thing since it does not run in the app, but inside the IDE. Why in the world would this specific column be causing this problem?
Description
we should just pass the same identity.
This is only a backwards compatibility issue and will crash for Room instances that were compiled w/ the old room version.