I've added this to our backlog for the time being but I'd be happy to bring it into a 5.3.x release soon.

To get started, ideally we'd have at least a sketch of what such a method's implementation should look like. Are we trying to make this fully pluggable or are we rather just baking in some common cases out of the box, leaving the rest up to custom mapping functions?

Generally speaking, it would be convenient to use Spring Data (or any other mapping framework) if it is on the classpath when mapping query results, regardless of the SQL connector technology (JDBC or R2DBC). A pluggable variant could provide streamlined instantiation strategies (for example reflection-less) or apply column-name mappings but it comes with increased complexity and the need for an SPI.

A non-pluggable arrangement could serve for the most common use-cases. Such an API needs to differentiate whether the target type is expected to map onto a single column (as(Long.class) (Java-primitive), as(LocalDateTime.class) (R2DBC primitive), as(Blob.class) (R2DBC primitive), as(Json.class) (R2DBC Postgres primitive)) or whether the result should be mapped onto a data class/record/POJO.

Since R2DBC driver primitives vary across drivers, it doesn't make sense to update our framework code for each new driver that we discover. I wonder whether it would make sense to provide an API on R2DBC level that allows consumers to identify R2DBC and driver primitives (r2dbc/r2dbc-spi#192).

Could we port BeanPropertyRowMapper to R2DBC?

Any updates on that ?!

It seems org.springframework.data.r2dbc.core.DatabaseClient.as(--) was also doing some kind of magic to Instant type fields. Because when I use org.springframework.r2dbc.core.DatabaseClient.map instead and map like row.get("...", Instant.class), it loses the TZ info and I get it in local time zone.

@mp911de

Right now, mapping requires a mapping function to be used through map(BiFunction<Row, RowMetadata, T>).

How to handle custom converters in this case? I have some JSONB field, which requires custom converter, and when I'm trying to call row.get("fieldA", "MyCustomType::class.java") in the mapping function, I'm getting:

Suppressed: java.lang.IllegalArgumentException: Cannot decode value of type MyCustomType at io.r2dbc.postgresql.codec.DefaultCodecs.decode(DefaultCodecs.java:153) at io.r2dbc.postgresql.PostgresqlRow.decode(PostgresqlRow.java:90) at io.r2dbc.postgresql.PostgresqlRow.get(PostgresqlRow.java:77)

Not sure whether this is the right issue to report this, but the documentation still says 'as' is supported. Is the documentation wrong or has this issue been resolved ?

See here:

https://spring.io/projects/spring-data-r2dbc

which has this example code in it:

Flux<Person> all = client.execute() .sql("SELECT id, name FROM person") .as(Person.class) .fetch().all();

Not sure whether this is the right issue to report this, but the documentation still says 'as' is supported. Is the documentation wrong or has this issue been resolved ?

See here:

https://spring.io/projects/spring-data-r2dbc

which has this example code in it:

Flux<Person> all = client.execute() .sql("SELECT id, name FROM person") .as(Person.class) .fetch().all();

No thats not available anymore and is deprecated.

Following up on @schauder suggestion to port BeanClassRowMapper from JdbcTemplate, a port of DataClassRowMapper would also be helpful (for records).

There seems to be a bit more depth to this issue, but I'm in the process of porting the BeanPropertyRowMapper and DataClassRowMapper as R2DBC-compatible mapping functions. This is explored in PR gh-30530 (which doesn't supersedes this issue).

Note that something similar is available through query(Class) on the new JdbcClient in 6.1. See #30931 and #26594 (comment) for the context there.

Unfortunately, this is not totally straightforward to provide with the R2DBC DatabaseClient since we do not have the equivalent of SingleColumnRowMapper and SimplePropertyRowMapper there yet. We'll see what we can do about it, along with #27282 for parameter source objects along the lines of paramSource(Object) on JdbcClient.

I'm introducing a mapProperties(Class) method on DatabaseClient, supporting bean properties and record components for creating a result object per row. In addition, the accompanying mapValue(Class) provides a simple as-style mapping to a database-supported value type, extracting the first column with the given type via the R2DBC driver.

In contrast to JdbcClient, those are provided as distinct methods rather than a unified map(Class) since there is no good rule for differentiating between a database-supported value type and a bean/record. The mapProperties variant uses DataClassRowMapper whereas mapValue calls the corresponding Row.get method with index 0 and the given type.

Note that plain field holders are not supported since this does not seem idiomatic with R2DBC. Record classes or custom classes with constructors and/or bean-style accessors can be very concise and are actually better suited for inline use in a reactive pipeline, this is showing particularly well for parameter objects (#27282) which we also support now.