Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal to expose PgClient functionality through R2DBC API #249

Open
mp911de opened this issue Feb 28, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@mp911de
Copy link

commented Feb 28, 2019

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.

@vietj vietj added the help wanted label Feb 28, 2019

@mp911de

This comment has been minimized.

Copy link
Author

commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

@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

This comment has been minimized.

Copy link
Collaborator

commented Apr 5, 2019

@pratikpparikh

This comment has been minimized.

Copy link

commented Apr 7, 2019

@mp911de nice work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.