Status Update
No update yet.
Comments
da...@google.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:
kp...@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: Room 2.0.0-alpha05
Devices/Android versions reproduced on: Any
Recent deprecations influence business logic flow a lot. Example: remote server's response parsing (I think, rather common case).
Old way:
// JSONException is thrown upper, so it can be managed alltogether with HTTP response errors (for example, just ignored to use old data on unexpected response format)
public void parseResponse(final JSONObject obj, final JSONArray subObjs) throws JSONException
{
db.beginTransaction();
try {
final DBItem item = db.getDaoItem().findItem(obj.getLong("id"));
item.parseSomehow(obj); // throws JSONException on failure
final DBSubItem[] subitems = db.getDaoSubItem().findSubItems(item.getId());
db.getDaoSubItem().replaceSubItems(item.getId(), DBSubItem.parseSomehow(subObjs)); // replaces, reusing subitems with updating inner order; throws JSONException on failure
db.setTransactionSuccessful();
} finally {
db.endTransaction();
}
}
New way (looks worse, no exception type control - so you can throw anything and check it only in runtime):
public void parseResponse(final JSONObject obj, final JSONArray subObjs) throws JSONException
{
try {
db.runInTransaction(() -> {
... // same code as in previous example inside try...catch
return null;
});
} catch (RuntimeException e) {
if (e.getCause() instanceof JSONException) {
throw (JSONException)e.getCause();
} else {
throw e;
}
}
}
Of course, I can try to separate parsing from database interaction, but it would require at least temporary objects with no more usage (in the project's code). Additionally, sometimes next parsing steps depend on previous / storage data.
Final thoughts. Looks like runInTransaction should be recommended method in most situations, but the old way is still convenient too.