If anybody was looking for an async postgres library, I just found this: https://github.com/vietj/reactive-pg-client (J. Viet is the head of the Vert.x team), I just didn't try it yet, but it looks promising... if it's based on the Vert.x version it looks stable (I have production code on the Vert.x version). It even has Kotlin docs https://www.julienviet.com/reactive-pg-client/guide/kotlin/index.html

It has lots of dependencies on vert.x as far as I can see, which is perfectly understandable, but isn’t it kinda make it too complex to use it outside of vert.x?

I know the Vert.x version needs to have a Vertx instance passed to it, this lib looks more independent (although you're right, I just looked at the pom file and found all those vertx dependencies...). What are your concerns about being more complex?

I don’t really understand the point of specialized async access to db (whether the one you just listed or the new JDK effort). It’s trivial to take the current sync API and make it async with a lot of options and variety (Rx, coroutines, etc…)

It is not. First you need to have async connection pool that is not blocking a thread. Then you need to send request to SQL server and suspend (not block) until it responds. Then, ideally, you would receive rows for the result set in an async way, like in a channel or so, and do not block thread and not fill in your RAM with all the received raws before returning it to client.

And all that is covered by the Vert.x client...

well you can't use any ORM on top of it since it doesn't use JDBC

I see

and from what I remember it boots a vertx server which isn't exactly lightweight

So the real work would be at the JDBC driver level, right?

This perticular library? @fred.deschenes

(and database itself too obviously)

well any "async" SQL library (this one included)

I mean booting full vertx? I don't think it would deploy verticles behind the scenes or anything..

honestly until the new async JDBC (whatever they called it, can't remember) I don't think it's worth it trying to work with those libraries (although they are a good way to figure out what to do and not to do in the real async implementations that will come eventually)

@cedric Node.js works like this too, the "event loop" of the app keeps on receiving requests and running queries, and gets responses and sends them in callbacks, effectively not blocking any threads and being able to process many more requests w/ less resources...

We are preparing to do it for #squash as well. @Deactivated User got a prototype for MySQL, and we have a branch with suspending function, but no connection pool yet.

Ok… squash?

Is there some kind of idea of a release date @orangy?

Ah https://github.com/orangy/squash

My fork (with the suspending stuff): https://github.com/soywiz/squash And the MySQL CIO client (along other clients like redis): https://github.com/soywiz/ktor-cio-clients Still WIP, but somehow works. Also those are temporal repos until merged. But I put in the case you are curious about it.

Very interesting... 😉

suspending stuff minus other related work is in branch for squash already, but I’m not yet sure how to promote it to master. It will require after user to wrap in

runBlocking

or something similar, unless they use #ktor already of course 🙂

Nice. I think it is almost done modulo bugs and remaining cleanups (did some additional work last friday night by reducing GC and added some protocol-level redis tests). Of course it will require stress tests and some time of heavy use to determine that everything is working fine. But at least it is a start 🙂 and brings some of the benefits of Node.JS clients. I will check later the status of those repos, clean up the things that are already migrated to coroutines library, and see if I can publish cio clients to bintray in the meantime so the squash fork including the mysql pure async client can work. We have to see where to put those cio clients once they are done. They depend on

ktor-network

for raw sockets, that only depends on

kotlinx.coroutines

. So they should be pretty stand alone.

We will be shuffling stuff between kotlinx.coroutines, kotlinx.io, ktor to extract useful and self-contained libs for building other stuff in the Kotlin ecosystem.

Sounds great!

I tried using the impossibl Postgres driver (https://github.com/impossibl/pgjdbc-ng)

Wait for sql2

Yes, that’s what I see all the time when I ask about async sql