hello @here, i am new to compose desktop, i wanted...

# compose-desktop

[Samson Jisso]

hello @here, i am new to compose desktop, i wanted to add database functionality using SQLDelight, but i couldn't figure it out, i need help, templates would be helpful,

[sasikanth]

There are SQLDelight samples in the repo itself. Hopefully that's useful
https://github.com/cashapp/sqldelight/tree/master/sample

[hfhbd]

Just use JDBC: https://github.com/hfhbd/ComposeTodo/blob/main/desktop/build.gradle.kts

[Pablichjenkov]

You can check this one out. Not using SQLDelight extensively but the integration is there.
https://github.com/pablichjenkov/kmp-amadeus-api/blob/main/amadeus-api/src/jvmMain/kotlin/com/pablichj/incubator/amadeus/storage/DesktopDriverFactory.kt

[Michael Paus]

@hfhbd Using JDBC is not such a good idea because it is not a multiplatform solution. It binds you to Java.

[jw]

So does Compose Desktop

[Michael Paus]

The OP asked for Compose Desktop but this does not exclude the possibility to later extend that to, e.g., iOS. I just wanted to make him aware of the fact that he is leaving the multiplatform ground by using JDBC.

[hfhbd]

Sqldelight is multiplatform, but each platform needs a specific driver, like you need a platform runtime/window management. So I don’t get your point.

[Michael Paus]

Yes, but that is just adding one platform specific dependency. How would you get a solution based on JDBC running on iOS?

[jw]

You wouldn't, the same way you wouldn't expect a Compose Desktop app to just work on iOS either.

[jw]

The driver is the variance mechanism that allows the rest of SQL delight to be multiplatform. So you'd vary that with expect/actual or inversion of control. There's no point in pre-engineering some indirection here because the driver already provides it.

[Michael Paus]

You’re comparing apples with oranges. The SQLDelight API is multiplatform and JDBC is not. Of course you can try to re-invent something like SQLDelight but I don’t see why anybody should do that.

[jw]

I'm not sure what I'm comparing

[jw]

Why would you reinvent SQL delight when it's already multiplatform?

[jw]

Why would you worry about using JDBC when you're on the JVM?

[Michael Paus]

1. You are comparing one API which is multiplatform (SQLDelight) against another one (JDBC) which is not.
2. I am of course not proposing to reinvent SQLDelight. I said that when you use JDBC directly and you wrap your code, which is written agains its API, in expect/actual pairs to make it multiplatform, you basically are already creating some minimalistic reinvention of SQLDelight because you duplicate some of its functionality.
3. That’s a matter of opinion, of course but in the light of recent developments at the WASM front it is quite likely that in a not so distance future you might want to switch from JVM to WASM and then it would have been a good idea to have programmed agains a multiplatform API right from the beginning.

[hfhbd]

We always talk about using SqlDelight with the JdBC driver, not plain JDBC.

[Michael Paus]

Ok, that makes sense then but you should have made that clearer. I am actually using that myself too.

implementation("app.cash.sqldelight:sqlite-driver:$sqldelightVersion")

I thought you where proposing to directly use JDBC instead of SQLDelight.