Open
Description
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
andPgPool
Connection
->PgConnection
Statement
-> Utility to build/prepare a statement, eventually callingPgConnection.query(…)
orPgConnection.preparedQuery(…)
methodsResult
->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.