I’m curious about some of the design consideration...

# squarelibraries

[Alexander Ioffe]

I’m curious about some of the design considerations behind SqlDelight’s NativeSqlDriver. Why was a ThreadLocalRef chosen to carry around the open-transaction connection instead of a CoroutineContext? Are coroutines too performance-heavy for mobile use-cases?

[Derek Ellis]

SQLDelight was built around making blocking calls with no integration with coroutines at all (up until recently to support inherently asynchronous drivers which is not related here).

Threads are the only way to manage the transaction connections with the blocking APIs that SQLDelight exposes

[Alexander Ioffe]

Totally makes sense if your target is async drivers, I've had to do similar things in some of my DBC libraries. Was there an explicit reason to not rely on coroutines? Are there performance issues with things like suspendCancellableCoroutine?

[Derek Ellis]

At the end of the day it doesn't matter if you wrap it in a suspendCancellableCoroutine because it's a blocking call. It will block the coroutine.

[Derek Ellis]

The (original) SQLDelight APIs reflected that blocking nature, and so it's up to the consumer to ensure that it doesn't block the main thread or anything

[Alexander Ioffe]

original?

[Derek Ellis]

As in the regular APIs that have been around since long before the async stuff was introduced

[Alexander Ioffe]

You mean the async-extensions ?

[Derek Ellis]

The generateAsync thing for R2DBC and web workers

[Alexander Ioffe]

So the idea was that it should be up to the users to put the DB calls into blocking pool?

[Derek Ellis]

Yes

[Alexander Ioffe]

Wow. Interesting! I've been maintaining a JVM library that supports both blocking and non-blocking modes and basically its two completely different implementations (i.e. leading to 2x the code... which is tough). How have users responded to this "you do the Dispatchers.IO stuff" mantra over the years? If you had started from scratch today would you do the same thing?