IssueTracker

In the title I was meant to write 1 new column, not 2 new columns.

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?

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?

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.

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: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/room-compiler/src/main/kotlin/androidx/room/util/SchemaDiffer.kt;l=98

I'll fix this soon.

This is fixed, but sadly didn't make it into 2.4.0-alpha05, it'll be in the next release.

I have a similar issue here with dropped columns after a rename (no embedded annotation though), I'll file a different bug but it could be related

sorry I've commented on the wrong issue and it won't let me delete, please ignore!

yes, it will be but we are looking for some feedback before we make the switch just to be safe and not break other people.

Is it switched on by default in 2.2.5? Because I still got the message got a warning from kapt

[WARN] Incremental annotation processing requested, but support is disabled because the following processors are not incremental: androidx.room.RoomProcessor (DYNAMIC).

Solved to adding "room.incremental"="true" in the annotation params.

Oops, spoke too soon. First appears in the release notes for 2.3.0:

https://developer.android.com/jetpack/androidx/releases/room#2.3.0-alpha02

KNOWN ISSUE: Note that incremental Room is currently broken in some cases (Issue 159501719), so we may need to revert this change or send out a patch to at least provide workarounds to users. https://issuetracker.google.com//159501719#comment18 lists the possible fixes.

Sorry there was a typo, correction: https://issuetracker.google.com/159501719#comment18