Status Update
Comments
el...@google.com <el...@google.com> #2
For Kotlin 2.0 and KSP 2.0 the Cannot change attributes of configuration ':composeApp:debugFrameworkIosX64' after it has been locked for mutation
really seems like a KSP issue. You should file a bug in their repository with a sample app if possible.
If you downgrade to Kotlin 1.9 then things 'should' work, there are example apps out there with such configuration, like the following one:
ap...@google.com <ap...@google.com> #3
Will try to use the example provided by you to check if it fixes the issue.
el...@google.com <el...@google.com> #4
Note that this issue happens when applying the Compose, KSP and Room Plugin together in Kotlin 2.0.x, the workaround for now is to not use the Room Gradle Plugin and instead specify the schema location vis KSP arguments:
// In the build.gradle
ksp {
arg("room.schemaLocation", "${projectDir}/schemas")
}
xz...@gmail.com <xz...@gmail.com> #5
Hi, I encountered a similar problem and was able to resolve it by updating the dependencies
room = "2.7.0-alpha08"
ksp = "2.0.20-1.0.25"
compose-plugin = "1.6.11"
kotlin = "2.0.20"
pr...@google.com <pr...@google.com> #6
The following release(s) address this bug.It is possible this bug has only been partially addressed:
androidx.room:room-compiler:2.7.0-alpha06
xz...@gmail.com <xz...@gmail.com> #7
el...@google.com <el...@google.com> #8
Thanks for the update!
Description
Version used: 2.6.1
Devices/Android versions reproduced on: All
I have multiple tables where I must add a new `appId` column.
This new `appId` is part of my foreign key constraints.
The problem is that Room applies the table migration alphabetically but then checks for the foreign key constraints after each table migration.
Therefore, my foreign key is not OK since the old table doesn't have the new column yet.
Example:
Table_A: id, name, tableB_id
Table_B: id, name
Room will add the "appId" to Table_A and set the foreign key constraint to be on the columns `tableB_id` and `appId`, then execute:
DBUtil.foreignKeyCheck(db, "Table_A");
Yet, at that point, Table_B is still: id, name — and not: id, name, appId.