Proposal to expose PgClient functionality through R2DBC API

[mp911de]

R2DBC is an initiative to establish a common SPI for relational database drivers embracing reactive programming properties: Event-oriented, non-blocking, and ideally stream-oriented access to databases. R2DBC is built entirely on Reactive Streams defining a minimal API surface to be implemented by drivers without the need to re-implement common client functionality in every driver.

From an R2DBC perspective there are a couple of interfaces that could be implemented by using the following components of PgClient:

• ConnectionFactory -> PgClient and PgPool
• Connection -> PgConnection
• Statement -> Utility to build/prepare a statement, eventually calling PgConnection.query(…) or PgConnection.preparedQuery(…) methods
• Result -> PgRowSet
• Row -> (Pg) Row

What is the benefit of doing so?

Benefits:

• Following an API that is well-suited for client developers without the need to entirely change how the client is supposed to work
• Participating in a growing client-ecosystem (MyBatis, draft, JDBI, Spring) with clients providing a humane API. Application developers get a choice of which client they want to use for specific use-cases.
• With the choice of clients, PgClient isn't required to provide additional functionality such as object mapping or SQL generation. That's up to the client.
• Choice of plug and play for a growing eco-system of drivers beyond Postgres and MySQL (e.g. H2, Microsoft SQL Server) that can be used with vert.x.

Drawbacks:

• https://xkcd.com/927/
• Dependency on Reactive Streams (could be optional, still)
• Additional complexity by maintaining two driver frontends

Related ticket: #245.

[mp911de]

Here's a sketch how a PgPool could be exposed through the R2DBC API: https://gist.github.com/mp911de/9ea13939e8fd9a6b4ef138419f085715

It does not contain all the possible cases and requires a bit of work for prepared statements, however, it outlines the general idea.

[mp911de]

@vietj did you had a chance to have look at https://gist.github.com/mp911de/9ea13939e8fd9a6b4ef138419f085715 outlining the intended PR? If so, I could start working on a pull request. WDYT?

[vietj]

not yet, I've been very busy on other things (Vert.x 3.7.0 release)

…

On 5 Apr 2019, at 22:21, Mark Paluch ***@***.***> wrote: @vietj <https://github.com/vietj> did you had a chance to have look at https://gist.github.com/mp911de/9ea13939e8fd9a6b4ef138419f085715 <https://gist.github.com/mp911de/9ea13939e8fd9a6b4ef138419f085715> outlining the intended PR? If so, I could start working on a pull request. WDYT? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#249 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANxiua-HNE1SrsxRFw1sglB6AxVJgzJks5vd7BcgaJpZM4bWTPn>.

[pratikpparikh]

@mp911de nice work.

[Anisuka]

@mp911de good work, any idea on when this may be added to mybatis ?

[mp911de]

Check out https://gist.github.com/kazuki43zoo/2ede3dcbb857d7b23d685af08b5d4ea8 and mybatis/mybatis-3#1444. I’m not so much involved into MyBatis. However, MyBatis might need a bit of help to make R2DBC happen.

[jklingsporn]

jOOQ plans to support R2DBC within the next release and it would be nice to have a wrapper for vertx. @vietj have you any "official" plans/resources to implement R2DBC support/wrapper/client or do you consider this as a community project?
The biggest pain point I guess is the forced dependency to reactive streams in the API?

[lukaseder]

For the record, here's the link to the jOOQ issue: jOOQ/jOOQ#11700. It will ship with jOOQ 3.15 in Q2 2021. So far, no show stoppers have been found

[vietj]

we are not actively forward looking to implement R2DBC, but I think that anyone can provide an adapter project for this.

[moonaries90]

@mp911de good work, any idea on when this may be added to mybatis ?

https://github.com/moonaries90/mybatis-r2dbc-starter
I Just route about mybatis autoconfiguration. but i have no mysqlConnection to test, i used dev.miku packages. it is not very good

[lukaseder]

Another set of potential users of this integration (all via jOOQ):

• https://stackoverflow.com/q/72669626/521799
• Support async datasource drivers quarkiverse/quarkus-jooq#38
• Feature request: flavor for R2DBC async drivers (instead of JDBC) jklingsporn/vertx-jooq#205

While it seems that Red Hat isn't interested in moving forward with this (@vietj, why? Any background you can share on this decision? What would be needed to revert it?)

Is there any reason why @mp911de's work couldn't be published as one of these projects? https://r2dbc.io/drivers

[deusaquilus]

I'm curious about this too. Thinking about whether to implement a reactive driver for https://getquill.io/ but I can't support both R2DBC and VertX simultaneously. It's hard to move forward on this when there is no standard.