Official stance on suspend support ?

[mahmed1987]

I have seen discussions regarding Flows support for Sqldelight , however I am yet to find anything concrete on supporting suspending queries , like we have in Room Dao .

Basically my question is that does the code below suffice ?

class ProductDao {
    val productQueries = Db.productQueries

    suspend fun getProducts(): List<Product> {
        return productQueries.getProducts().executeAsList() // this however isn't suspending , because there is no icon in the gutter
    }

    suspend fun insertProduct(product: Product) {
        productQueries.insertProduct(product) // this however isn't suspending , because there is no icon in the gutter
    }
}

OR i would have to manually provide the context each time i access the db like the code below ?

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class ProductDao {
    val productQueries = Db.productQueries

    suspend fun getProducts(): List<Product> {
        return withContext(Dispatchers.IO) {
            productQueries.getProducts().executeAsList()
        }
    }

    suspend fun insertProduct(product: Product) {
        withContext(Dispatchers.IO) {
            productQueries.insertProduct(product)
        }
    }
}

unfortunately the lack of discussion on this makes me worried if we should even be adopting SqlDelight for our projects, despite the teams strong inclination towards this .

Please advise folks

[JakeWharton]

There is no suspend support for databases which are not intrinsically asynchronous.

Sqlite, for example, is a synchronous database. Thus, the APIs to interact with it from SQL Delight are also synchronous. The advantage of providing a synchronous API is that you can batch multiple database operations to occur with a single thread hop rather than having to ping-pong from the caller's dispatcher to the IO dispatcher for every operation. Additionally, synchronous databases almost always use thread-confined connections which means transactions only work from a single thread. Since a dispatcher does not guarantee on which thread you will run, you have to do a second dispatch to a thread-confined executor when within a transaction.

If the database is asynchronous (or at least the driver is), the functions can be generated as suspending. Unlike simply wrapping everything with withContext and blocking, this actually suspends and waits for the database to wake up the coroutine with results. Only certain databases on certain platforms support this.

There are no plans to do what Room is doing. In general we recommend observing queries with flows and batching mutating operations with explicit thread hops, potentially even using a dedicated dispatcher which runs on a single thread to avoid contention.

[mahmed1987]

Thanks @JakeWharton for the detailed answer.

I would recommend you folks to update the official sample app that is in the sqldelight repository so that some usage patterns can be demonstrated

The current sample app is pretty outdated (it uses multiple activities) and it accesses the database on the main thread.

There are not of guesses and estimates about the proper usage pattern of sqldelight in the community and it would really help if you folks could alot some engineers to create a NowInAndroid kind of application depicting various usecases.

Thank you

[JakeWharton]

SQL Delight is not a supported product or anything, it's an open source project done in various engineer's spare time. The best way to make the sample more in tune with real life usage is to send PR contributions moving it in that direction. And I don't mean you specifically, but more any community members in general.