https://kotlinlang.org
Join Slack
In the R2dbc driver it says that json is supported using `String`... does that mean that it's also s...
# komapper
d
In the R2dbc driver it says that json is supported using 
String
... does that mean that it's also supported by Komapper?
t
mirromutth/r2db-mysql is not compatible with R2DBC 1.0. So Komapper does not support mirromutth/r2db-mysql. However, other drivers can map JSON types by using user-defined data types or data type conversion. See documentation for user-defined data types and data type conversion: https://www.komapper.org/docs/reference/data-type/#user-defined-data-types
d
🤒 OOps! I've been using the R2dbc api with h2 (for testing) so far... so to connect to mysql I'd have to convert all my code to jdbc and forget about coroutines support?
It seems like that one does support 1.0
We've been using that library in production for a while, and it seems to work pretty good.
(without the r2dbc driver, just using it's own api)
It might have been nice to have some kind of wrapper api that transforms a regular jdbc dialect to using coroutines... it would be blocking on the back end and maybe have some kind of thread pool converted to a dispatcher, but on the front end it would suspend and release the frontend's handlers to do other work meanwhile...
Just like blocking libraries like Retrofit for Android do... they are also blocking in the back end, but expose a coroutines interface for use.
It also looks like you started support... https://github.com/komapper/komapper/tree/1ea5be409ab0367e832ea0e89056d8c042c3447f/komapper-dialect-mysql-r2dbc would it be possible to take that code into my project, and just replace that driver for the jasync one?
t
I tried jasync-r2dbc-mysql 2.1.8 but could not run it in combination with Komapper. There seems to be an unimplemented API: https://github.com/jasync-sql/jasync-sql/blob/2.1.8/r2dbc-mysql/src/main/java/JasyncResult.kt#L45
d
Oh... we could see with @oshai the developer of the library... I wonder why that's not implemented? So is there maybe a way to just wrap the jdbc implementation in the meantime? Maybe just some kind of suspend version of runQuery and flowQuery on the JDBC implementation that uses a dispatcher with a thread pool?
If I migrate to jdbc, I'm still really using it on Ktor that doesn't really like blocking apis....
I would even maybe abstract out whether the implementation is JDBC or R2DBC from whether the DSL is using blocking or non-blocking apis... I don't know how much that would be possible the way Komapper is currently implemented... but there are still advantages with JDBC and non-blocking apis...
If there's any other api needed, I can add it to that issue...
t
So is there maybe a way to just wrap the jdbc implementation in the meantime?
You can achieve this by implementing the 
R2dbcDatabase
interface yourself.
d
How do I convert a flowQuery to a regular one to implement 
override fun <T> flowQuery(query: FlowQuery<T>): Flow<T> =
?
t
Cast it to the 
Query
interface.
d
And what about the 
withTransaction
?
t
Delegate to 
JdbcDatabase.withTransaction
. Note that JdbcDatabase manages transactions in ThreadLocal.
d
I could, I just need a 
CoroutineTransactionOperator
...
A not-so-nice start:
Copy code
class JdbcR2dbcAdapter(val db: JdbcDatabase) : R2dbcDatabase {
    override val config: R2dbcDatabaseConfig get() = TODO()

    override fun <T> flowQuery(query: FlowQuery<T>): Flow<T> = flow {
        val result = withContext(<http://Dispatchers.IO|Dispatchers.IO>) { db.runQuery(query as Query<T>) as Iterable<T> }

        result.forEach { emit(it) }
    }

    override fun <T> flowQuery(block: QueryScope.() -> FlowQuery<T>): Flow<T> = flow {
        val block = block as QueryScope.() -> Query<T>
        val result = withContext(<http://Dispatchers.IO|Dispatchers.IO>) { db.runQuery(block) as Iterable<T> }

        result.forEach { emit(it) }
    }


    override fun <R> flowTransaction(
        transactionAttribute: TransactionAttribute,
        transactionProperty: TransactionProperty,
        block: suspend FlowCollector<R>.(FlowTransactionOperator) -> Unit
    ): Flow<R> {
        TODO("Not yet implemented")
    }

    override suspend fun <T> runQuery(query: Query<T>): T = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
        db.runQuery(query)
    }

    override suspend fun <T> runQuery(block: QueryScope.() -> Query<T>): T = withContext(<http://Dispatchers.IO|Dispatchers.IO>) {
        db.runQuery(block)
    }

    override suspend fun <R> withTransaction(
        transactionAttribute: TransactionAttribute,
        transactionProperty: TransactionProperty,
        block: suspend (CoroutineTransactionOperator) -> R
    ): R {
        TODO("Not yet implemented")
    }
}
I guess the 
<http://Dispatchers.IO|Dispatchers.IO>
pool should maybe be limited... but otherwise do you see any other problems with this implementation?
I don't know if the cast to 
Iterable<T>
is right in the flowQuery implementations...
160 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by