Status Update
Comments
da...@google.com <da...@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>
ma...@justpinch.com <ma...@justpinch.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")
}
da...@google.com <da...@google.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"
Description
Component used:androidx.room:room-*
Version used: 2.3.0, 2.4.0-alpha02
Devices/Android versions reproduced on: N/A -> code-gen error (kapt)
The documentation on states:
@Transaction
But unless I'm misunderstanding what this is trying to communicate, reality seems to be different.
Given the following dao:
Although implementations are generated, errors are thrown for the
@Transaction
annotated functions returningLiveData
andFlowable
:This seems to contradict the earlier statement from the documentation on
@Transaction
? Is there another way to use@Transaction
with a deferred/async return type?What's also interesting is that the
@Transaction
annotated function returning aFlow
does not yield any errors. Isn'tFlow
also a deferred/async return type? Does this mean that Room can in fact guarantee that all queries in the method are performed on the same thread? If so, how?The generated code looks like this:
This function is no longer deferred, because the transactional operations involve blocking I/O, and there are assertions in place that will fail if this is called from the main thread. And even if we were to make this function suspendable (we would then have a suspendable function returning a Flow?🤨), it would still not be main-safe.
In conclusion, I suspect:
@Transaction
is no longer accurate?@Transaction
annotation returning aFlow
should also yield a code-gen error?