With R2DBC 0.9, a couple of changes were introduced that would make sense to be used by applications. Specifically:
- Usage of extensible transaction definitions
- Introduction of
io.r2dbc.Parameter - Deprecation of
RowMetadata.getColumnNames()in favor ofRowMetadata.getColumnMetadatas()
Usage of extensible transaction definitions
Connection.begin(TransactionDefinition) was introduced to allow drivers to consider a full transaction definition instead of requiring calling code to set individual options requiring individual server-roundtrips in the worst case. R2dbcTransactionManager.doBegin sets the isolation level and then calls begin() without providing hooks for customization (in fact, beginning a transaction with an isolation level is one of the driving use-cases).
It would be good to extract calls to prepareTransactionalConnection and Connection.begin into a template method for customization purposes.
Relationship of o.s.r.core.Parameter to io.r2dbc.Parameter
The Parameter type was introduced with R2DBC 0.9 so a future revision of Spring Framework (Framework 6) could deprecate o.s.r.core.Parameter. Drivers accept io.r2dbc.Parameter via bind(…) and that type doesn't interfere with DatabaseClient when using R2DBC 0.9.
The use of io.r2dbc.Parameter also allows specifying parameter directions (IN/OUT/IN-OUT) which is useful in stored procedures arrangements, however consumption of out parameters isn't possible as the newly introduced API isn't available in R2DBC 0.8.
ColumnMapRowMapper
We should switch to RowMetadata.getColumnMetadatas() to obtain column names. The return type of getColumnMetadatas was changed in R2DBC 0.9 to List as it was Collection in 0.8. So reflection is required here to address binary compatibility issues.
Comment From: sbrannen
Related issues:
-
27902
Comment From: jhoeller
Let's use this issue for R2DBC API alignments in spring-r2dbc, to be applied in a 6.0 milestone. We can raise the baseline to R2DBC 0.9 there, so there shouldn't be a need for reflective adaptation. We'll just use R2DBC 0.9 proper, as long as the timeline works out for our GA in November.
For 5.3.x, we could simply stay at the R2DBC 0.8 level for compilation and aim for runtime compatibility with 0.9. Even if we choose to build against R2DBC 0.9 and aim for runtime compatibility with 0.8 instead, I'd keep using getColumnNames() with @SuppressWarnings("deprecation") for the time being, avoiding reflective adaptation as far as possible.
Comment From: mp911de
We can certainly do so. We plan to ship in fact R2DBC 1.0 GA until Q2/2022 so it can be used by Spring Framework 6 and other frameworks that decide to release later this year.
Comment From: jhoeller
Oh even better, if R2DBC 1.0 is GA in time, we can even go with that as a baseline for Spring Framework 6.0 indeed.
For 5.3.x, it's mostly about Boot alignment. We could keep building against R2DBC 0.8 there... but if Boot decides to upgrade to R2DBC 0.9 for all of its supported branches (for H2 2.0 support), we could just as well build against R2DBC 0.9 and retain runtime compatibility with 0.8 for spring-r2dbc itself. Some initial local tests didn't reveal any issues other than needing an @SuppressWarnings for getColumnNames() against the existing implementation, with all the tests passing again then.
Comment From: mp911de
I can provide a PR that outlines the desired changes. Probably we need another round with DatabaseClient to provide an API to consume stored procedure results.
Comment From: jhoeller
That would be much appreciated, @mp911de, in particular if you got a sketch of it in mind already. Let's do the R2DBC 0.9 part for 6.0 M3 and then see what the move to R2DBC 1.0 brings for 6.0 ~M5.
Comment From: wilkinsona
We could keep building against R2DBC 0.8 there... but if Boot decides to upgrade to R2DBC 0.9 for all of its supported branches (for H2 2.0 support)
We'd like to upgrade to H2 2.0 in Boot 2.7.0, and ideally in 2.7.0-M2. R2DBC 0.9 is the last piece in the puzzle there with other projects that don't rely on H2's API anywhere near as much being H2 2.0 compatible already in their recent maintenance releases.
Comment From: mp911de
I started a branch for R2DBC 0.9 changes and filed a few tickets to simplify testing and a bug report in R2DBC H2. Once these are addressed, we can continue with the R2DBC 0.9 upgrade.
Related tickets:
- https://github.com/r2dbc/r2dbc-spi/issues/260
- https://github.com/r2dbc/r2dbc-h2/issues/219
Comment From: jhoeller
Superseded by PR #28059.