Making the driver async

[eygraber]

I am strongly considering making the driver async (the underlying SQLite APIs are still blocking though). This will allow more efficient integration with the connection pool that I've added to it, as well as make it possible to handle all of the details about dispatching internally, so SQLDelight APIs can be used without worrying about what CoroutineDispatcher you are using.

It would be a breaking change, though the migration path should be pretty straightforward.

I'm not sure what the options would be if you wanted to use it in a non suspending context.

sqldelight/sqldelight#5967 would have to be released before this would happen.

Thoughts, questions, concerns?

[Nek-12]

What will be the actual benefit to end users who will have to migrate, and what will that entail?

[eygraber]

The main benefit will be not having to worry about CoroutineDispatcher when interacting with the driver / SqlDelight, and thread affinity is handled for you in WAL mode and transactions.

An ancillary benefit is that the library is going to be easier to maintain.

I have to write up a migration guide, but the gist is:

• set generateAsync = true in the Gradle plugin extension
• use await* functions instead of execute*
• a different set of Flow extensions should be used (which this library will provide) because the SqlDelight ones require a CoroutineDispatcher (which isn't necessary with the async implementation)

[Nek-12]

That'll be ~16 hrs of migration work for us (single module). Lucky we are following clean arch well.

I'm not against it, but I'd prefer if I could pick when I migrate instead of being forced to do it on dependency upgrade.

[eygraber]

Are you currently calling execute* and transaction in a suspend function? If so, the migration is probably mostly scriptable / find&replace.

If possible, can you share what aspect of your SqlDelight usage would make it more complicated? I'd like to make this migration as smooth as possible.

I'd prefer if I could pick when I migrate instead of being forced to do it on dependency upgrade

The main reason I haven't merged the PR yet is because I'm still thinking about how to provide something like this (either extracting the common code and having two separate drivers, or having a blocking driver wrap the async one), and if it is feasible.

[Nek-12]

If you'd like to, @eygraber, you can make a snapshot for this and i'll test it and tell you how hard the migration was on our 160k LoC production app. Maybe it's better than i think it is.

[eygraber]

I'm blocked on sqldelight/sqldelight#5967 but I can try to build something locally and make a snapshot out of that. The other alternative is to build it yourself locally and use mavenLocal (which is what I've been doing for testing).