spring-projects
Auto-configure jOOQ with R2DBC
Jooq added official R2dbc support since 3.15 , see: https://blog.jooq.org/reactive-sql-with-jooq-3-15-and-r2dbc/
Add JooqAutoConfiguration for R2dbc support, including compatibility with the existing transaction, data types, converters etc.
Recent jOOQ 3.x releases require Java 11 which makes upgraded problematic in 2.x where we have a Java 8 baseline. We may be able to look at this in 3.x.
jOOQ 3.18.0 is aligned with R2dbc 1.0 spec which is compatible with Spring Boot 3.x now, it is time to add R2dbc/Jooq Autoconfiguration.
@giger85 No, I'm afraid not. We work in the open so updates will appear in this issue when we have them. Right now, the issue is in the 3.x milestone. This means that we hope to work on it for a 3.x release but do not know when that will be. We have other, higher priority, items to focus on at the moment.
I have used jOOQ and R2dbc in a project for over one year, it is easy to integrate them in projects yourself.
Just need to create a DslContext bean that based on the R2dbc ConnectionFactory.
https://github.com/hantsy/spring-r2dbc-sample/blob/master/jooq-kotlin-co-gradle/src/main/kotlin/com/example/demo/domain/JooqConfig.kt
But unfortunately, the Spring tx, R2dbc context mapping, etc are not applied to jOOQ SQL execution.
Our strategy is only using jOOQ for complex query(across multiple tables, Db built-in functions, etc.), all create/update/delete and simple query operations use the existing Spring Data R2dbc.
@giger85 No, I'm afraid not. We work in the open so updates will appear in this issue when we have them. Right now, the issue is in the 3.x milestone. This means that we hope to work on it for a 3.x release but do not know when that will be. We have other, higher priority, items to focus on at the moment.
Hi @wilkinsona , I guess it is time to check in 3.3 as we are starting new journey from today
@giger85不，恐怕不行。我们公开工作，因此一旦有更新，就会出现在这个问题中。目前，这个问题处于 3.x 里程碑中。这意味着我们希望为 3.x 版本进行改进，但不知道什么时候。我们目前还有其他优先级更高的项目需要关注。
你好@wilkinsona我想是时候入住 3.3 了，因为我们从今天开始新的旅程
hello!spring-boot-starter-jooq and spring-data-r2dbc can be configured automatically? In which version?
hello!spring-boot-starter-jooq and spring-data-r2dbc can be configured automatically? In which version?
It is easy to configure them yourself. Check the jOOQ/R2dbc examples in https://github.com/hantsy/spring-r2dbc-sample
BTW, I have used jOOQ/R2dbc/Kotlin Coroutines in production for over 3 years.
hello!spring-boot-starter-jooq and spring-data-r2dbc can be configured automatically? In which version?
It is easy to configure them yourself. Check the jOOQ/R2dbc examples in https://github.com/hantsy/spring-r2dbc-sample
BTW, I have used jOOQ/R2dbc/Kotlin Coroutines in production for over 3 years.
thank for your examples, it can be running!But i still want to know if 'spring-boot-starter-jooq' and 'spring-data-r2dbc' can be configured automatically.
Can anyone clarify the state of jOOQ 3.19.11 and Spring Boot 3.3 integration with R2DBC?
I have a microservice that uses DatabaseClient from spring-r2dbc. I simply inject the DatabaseClient bean into my repositories and handle all the SQL work manually, without using Spring Data R2DBC.
I am considering switching to jOOQ to build SQL queries and, preferably, handle DB interactions as well.
I have configured the jOOQ DSL context bean like this:
final var settings = ...
return DSL.using(
new TransactionAwareConnectionFactoryProxy(connectionFactory),
SQLDialect.POSTGRES,
settings
);
In my repositories, it is used as follows:
final var query = dslContext.select(...).from(...).where(...).orderBy(...);
return Flux.from(query).map(r -> r.into(POJO.class));
Is this the right approach? Am I losing anything by using jOOQ compared to the "native" Spring R2DBC DatabaseClient, such as:
- broken Spring transaction management
- connection pooling
- resource management
- anything else?
Our projects(3 years in production) only use jOOQ for complex queries across multiple tables. No need Spring transaction integration here.
Others(simple queries by repository, mutation, etc) use Spring R2dbc/Spring Data R2dbc directly.
Can anyone clarify the state of jOOQ 3.19.11 and Spring Boot 3.3 integration with R2DBC?
I have a microservice that uses
DatabaseClientfromspring-r2dbc. I simply inject the DatabaseClient bean into my repositories and handle all the SQL work manually, without using Spring Data R2DBC.I am considering switching to jOOQ to build SQL queries and, preferably, handle DB interactions as well.
I have configured the jOOQ DSL context bean like this:
final var settings = ... return DSL.using( new TransactionAwareConnectionFactoryProxy(connectionFactory), SQLDialect.POSTGRES, settings );In my repositories, it is used as follows:
final var query = dslContext.select(...).from(...).where(...).orderBy(...); return Flux.from(query).map(r -> r.into(POJO.class));Is this the right approach? Am I losing anything by using jOOQ compared to the "native" Spring R2DBC DatabaseClient, such as:
- broken Spring transaction management
- connection pooling
- resource management
- anything else?
I only used jooq to query select。other still used spring-data-r2dbc.
Our projects(3 years in production) only use jOOQ for complex queries across multiple tables. No need Spring transaction integration here.
Others(simple queries by repository, mutation, etc) use Spring R2dbc/Spring Data R2dbc directly.
I am interested if it is safe to use jOOQ for everything with my DSLContext configuration. Or I am missing something.
The situation with transactions, R2DBC and jOOQ is pretty complicated. There are a number of jOOQ issues tracking various improvements in jOOQ and also some that are still outstanding, for example:
- https://github.com/jOOQ/jOOQ/issues/12218
- https://github.com/jOOQ/jOOQ/issues/13502
- https://github.com/jOOQ/jOOQ/issues/16109
There's also a Spring Boot issue about improving the jOOQ transaction experience with JDBC. In that context, I think we should be quite wary about adding R2DBC support where transactions are harder to get right. Demand for this integration seems to be pretty low so I don't think this should be a priority and I even wonder if it's something that we should tackle at all as the complexity and potential maintenance burden seem rather high for something that looks like it will be of limited benefit.