Curious why there is no coroutines-friendly alternative to `SupportSQLiteOpenHelper`. So, suspend fu...

# android

[Mark]

Curious why there is no coroutines-friendly alternative to SupportSQLiteOpenHelper. So, suspend funs for getReadableDatabase() etc, and a callback with suspend fun onUpgrade() etc.

[Adam Powell]

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

[Adam Powell]

@danysantiago might be able to tell you more if he's not already on holiday for the next week or so 🙂

[Mark]

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()?

[Dominaezzz]

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.

[Mark]

Is it only an issue for transactions?

[Dominaezzz]

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

[Dominaezzz]

Yes just transactions.

[Dominaezzz]

onUpgrade is (or at least should be) called in a transaction.

[Mark]

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