Spring R2DBC DatabaseClient.as(…)
Asked Answered
C

1

17

In my spring-boot 2.3 application, I have a simple data method using DatabaseClient:

fun getCurrentTime(): Mono<LocalDateTime> =
    databaseClient
        .execute("SELECT NOW()")
        .asType<LocalDateTime>()
        .fetch()
        .first()
}

With spring-boot 2.4 (and spring 5.3 and spring-data-r2dbc 1.2), org.springframework.data.r2dbc.core.DatabaseClient from spring-data-r2dbc is deprecated in favor of org.springframework.r2dbc.core.DatabaseClient of spring-r2dbc - which has a different API.

Adapting that is pretty much straightforward - with the exception of the kotlin extension asType, which is not a part of the new DatabaseClientExtensions.

fun getCurrentTime(): Mono<LocalDateTime> =
    databaseClient
        .sql("SELECT NOW()")
        .map { row: Row ->
            row.get(0, LocalDateTime::class.java)!!
        }
        .one()

Are those extensions somewhere else or how can I convert using a reified type parameter?

Capsicum answered 2/11, 2020 at 14:35 Comment(0)
V
14

TL;DR

There's no as(Class) API after the migration to Spring R2DBC.

A bit of background

DatabaseClient started its journey in the experimental Spring Data R2DBC project, trying out various approaches. One of them evaluated how close a textual SQL API and an object-mapping API could be brought together. DatabaseClient in Spring Data exposed various API methods such as select().from("table").as(targetType).

It turned out that this functionality is useful but draws certain limitations because the more an API goes into an entity or even aggregate-oriented direction, the more complexity the actual API becomes and at some point, boundaries between simple object mapping and entities (for example, entity lifecycle callbacks) blur.

We decided to introduce R2dbcEntityTemplate as an abstraction for all entity-bound operations to support most common use-cases. Looking at the fluent API that was previously in place, there's still a gap for all use-cases that require ad-hoc SQL queries, aggregations, function calls, etc.

In the meantime, the project proved useful, and we've identified core support classes that could be migrated into Spring Framework 5.3, so Spring Data R2DBC 1.2 could be based on top of Spring R2DBC.

We weren't able to come up with a proper approach while migrating the code. To be fair, DatabaseClient offers almost the same level of abstraction (except for stored procedures) as NamedParameterJdbcTemplate. Spring JDBC ships clearly with several RowMapper implementations such as SingleColumnRowMapper or DataClassRowMapper that would be useful for Spring R2DBC, too.

Final thoughts

From a user-perspective, as(…) sees a lot of demand and we should investigate, how this functionality (or a variant of it) could be surfaced.

Vitrescent answered 3/11, 2020 at 8:28 Comment(2)
Thank you for the insights! Mentioning R2dbcEntityTemplate was helpful, I'll use that for cases where a repository is not sufficient, e.g. for specialized JOIN queries.Kalinda
FWIW, I filed a ticket in Spring Framework: github.com/spring-projects/spring-framework/issues/26021Vitrescent

© 2022 - 2024 — McMap. All rights reserved.