Curious why there is no coroutines-friendly alternative to

SupportSQLiteOpenHelper

. So, suspend funs for

getReadableDatabase()

etc, and a callback with

suspend fun onUpgrade()

etc.

Others would be better equipped to answer specifics, but a significant portion of the sqlite android framework api relies on private internal ThreadLocals for maintaining transaction information. Room works around this for some coroutines-friendly APIs at a higher level by guaranteeing a CoroutineContext that involves the associated thread's scope

Thanks Adam, hmm I vaguely remember something about that threading aspect. Does that mean we shouldn’t be calling, for example,

SQLiteDatabase.execSQL()

from

<http://Dispatchers.IO|Dispatchers.IO>

but rather using something like

Executors.newSingleThreadExecutor().asCoroutineDispatcher()

?

Sqlite transactions can only be done on a single thread. It will be very unhappy if you start a transaction and jump to a different thread to execute a statement.

Is it only an issue for transactions?

Suspend functions do not guarantee single thread execution, unless you force it like room has.

I guess by keeping that as a plain old function, there is no realistic chance of thread switching, unlike if it were a suspend fun