IssueTracker

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: https://github.com/realityexpander/KMP_Room/tree/main

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")
}

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"

yea makes sense. Lets go with your first suggestion for now, maybe Dany will have a better idea.

I think onPopulated is a good starting point. Maybe a more specific name could be onOpenPrepackagedDatabase, we mention 'pre-package databases' a few in the documentation so maybe we can use that same term.

Meanwhile, let me clarify what I meant by 'opening the DB with a vanilla helper'. In SQLiteCopyOpenHelper once delegate.getWritableDatabase() is invoked it will actually open the DB and go through all the onCreate, migrations and onOpen callbacks which means if you add logic to call onPopulated it would have already been too late. My feeling is onPopulated should be called around the same time as onCreate, before migrations and before onOpen so that users get a chance to modify the pre-package DB, possibly making schemas changes to comply with Room's validation. Therefore, I think we need to temporarily open the DB just to pass it so onPopulated, we can do this with a new FrameworkSQLiteOpenHelper, then close the DB and let the delegate open it, which would go through the rest of Room's flow. Hope this makes sense!

do you mean doing it in the copying helper? Maybe even we can let createFromAsset builder methods to receive a callback which includes onPopulated?

Yeah, doing it on copying helper, it's the most accurate place where we know a pre-packaged DB was used / copied. The callback itself can also be receive in createFromAsset / createFromFile, or just a new callback in RoomDatabase.Callback, I still think the tricky part is giving a DB in the callback itself (onPopulated(SuppoertSqliteDatabase db)) which requires opening the DB in the middle of the 'opening sequence'.

thats why i thought about scoping it to createFromFile(file, callback) so that it would be responsibility of the createFromFile to open the database and call the callback and then close it.

now it makes me wonder if that callback needs to be full fledged open helper callback instead of a special on populated? What if we just let them pass the regular callback there and if that callback exists, they can do whatever.

Another problem is though, we don't know the version so how are we going to open it in the first place :/.

Seems reasonable to scope it and not be a full fledge callback. However, I still think it needs to be lazy called (when the DB is opened for the first time, usually on the first query done) and not when building the DB (via the builder). The callback is really only useful is it receives the DB as a param so the user gets a chance to do something, so still think we need to open the DB and close it.

By the way, we can read the DB version without opening the DB: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-master-dev:room/runtime/src/main/java/androidx/room/util/DBUtil.java;l=139

ugh thats a good point. Danny knows better but my first instinct is to let SQLiteCopyOpenHelper take care of calling it. It also needs to know that it is expected to open the database :/ so needs to keep track of that information as well not to open the database when it doesn't need to. we might possibly go a bit loose on transactionality and just keep an additional file next to the database to keep this information. the downside is that we'll be creating more junk that we can never delete.