Status Update
No update yet.
Comments
ch...@gmail.com
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:
ch...@gmail.com
Will try to use the example provided by you to check if it fixes the issue.
da...@google.com
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")
}
ap...@google.com
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"
Description
Version used: 2.2.0-alpha02
Devices/Android versions reproduced on: API 29
I'm hitting a weird issue where a Flow<T> from Room will randomly stop dispatching updates (usually after a few successful emissions). I've dug into this a bit and found this in my logs:
2019-08-10 15:29:39.928 19259-19367/app.tivi.debug E/DiscoverViewModel: Fail() during execute
java.lang.IllegalArgumentException: column '`show_id`' does not exist. Available columns: [id, request, entity_id, timestamp]
at android.database.AbstractCursor.getColumnIndexOrThrow(AbstractCursor.java:340)
at androidx.room.util.CursorUtil.getColumnIndexOrThrow(CursorUtil.java:108)
at app.tivi.data.daos.PopularDao_Impl$13.call(PopularDao_Impl.java:257)
at app.tivi.data.daos.PopularDao_Impl$13.call(PopularDao_Impl.java:249)
at androidx.room.CoroutinesRoom$Companion$createFlow$1$1.invokeSuspend(CoroutinesRoom.kt:81)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:241)
at androidx.room.TransactionExecutor$1.run(TransactionExecutor.java:45)
at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1412)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:285)
The columns listed in the exception have no relevance to the Flow query (they're from a completely different table). The table in question is also not mentioned in the generated calling code.
I *think* this is probably a cache invalidation issue, maybe in RoomSQLiteQuery.acquire, where the acquired query isn't properly invalidated so the "old" query is still being used?