<sqldelight-androidx-driver> provides a <SQLDeligh...

# feed

[eygraber]

sqldelight-androidx-driver provides a SQLDelight driver for AndroidX KMP SQLite!

Android and JVM are currently supported, and there is a PR adding support for iOS, Linux, and Mac (I'd appreciate if anyone with Kotlin Native experience could give it a review).

[rocketraman]

Can you explain the advantages of using this over the default SQLite driver provided by SQLDelight?

[rocketraman]

I guess no need for platform-specific driver creation?

[eygraber]

For Android it allows you to use the bundled androidx artifact that brings along a sqlite binary, so you don't have to rely on the platform one, and can use the latest version of sqlite.

And yes it removes the need for platform specific drivers, and has a standard API.

[rocketraman]

Does the bundled androidx artifact have Android specific optimizations or workarounds vs the platform one?

[eygraber]

They just mention that it's compiled from (sqlite) source, so it would have whatever Android specific optimizations and workarounds the newer versions of sqlite have.

[eygraber]

https://developer.android.com/kotlin/multiplatform/sqlite#driver_implementations

[rocketraman]

> has a standard API
SQLDelight already serves as my API abstraction, so does this matter?

> so you don't have to rely on the platform one, and can use the latest version of sqlite.
Hmm, isn't it the other way around? The sqlite version bundled by Android depends on the API version, whereas the one used by SQLDelight will always be whatever SQLDelight builds against. Which probably also means more consistent behavior in general, at the cost of a bigger app bundle size.

[rocketraman]

Hmm, the android driver in SQLDelight already uses androidx-sqlite: https://github.com/sqldelight/sqldelight/blob/master/drivers/android-driver/src/main/java/app/cash/sqldelight/driver/android/AndroidSqliteDriver.kt.

So I guess where this gets interesting is when the SQLDelight driver uses the same androidx APIs for native as well, which currently uses Touchlab's sqliter.

[eygraber]

Sorry I was on mobile before, hopefully I can explain more clearly now.

SQLDelight already serves as my API abstraction, so does this matter?

It abstracts away driver creation, which is not as big of a deal as the rest of the abstraction, but every little bit counts.

> so you don't have to rely on the platform one, and can use the latest version of sqlite.

Hmm, isn't it the other way around?

Nope, on Android if you use the SQLDelight provided AndroidSqliteDriver the version of SQLite used depends on the API version of Android. That means you need to do API version checks before using certain SQLite APIs and provide fallbacks (if possible) for previous versions.

Hmm, the android driver in SQLDelight already uses androidx-sqlite

Sort of 🙃

In google's latest questionable naming choice, they reused androidx.sqlite even though it currently exists as a wrapper around the platform's android.database.

The "new one" (which my library uses) is a complete break from the original androidx.sqlite and android.database and doesn't use any of those APIs.

If offers a completely new KMP API, with several implementations:

1. A wrapper around platform APIs
2. An implementation that uses a SQLite binary that Google builds from SQLite source
From their docs:

The recommended implementation to use is BundledSQLiteDriver available in androidx.sqlite:sqlite-bundled. It includes the SQLite library compiled from source, offering the most up-to-date version and consistency across all the supported KMP platforms.

The key here is that this implementation is used across all targets, so e.g. on native, sqliter isn't used. Android, iOS, JVM, Linux, and Mac all use the same abstraction and implementation.

[rocketraman]

Thank you!

[אליהו הדס]

It works with linux native ?

[rocketraman]

Once the PR @eygraber referenced is merged I think it should. The sqlite-bundled driver supports Linux: https://developer.android.com/kotlin/multiplatform/sqlite#driver_implementations.

[אליהו הדס]

Thanks, i will check this

[eygraber]

The PR was merged yesterday so it should be available. Any feedback on it would be greatly appreciated, since I personally don't have any native use cases.