You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of Spring Framework 5.3, the core framework has some dedicated r2dbc support. This has an impact on spring-data-r2dbc (see spring-projects/spring-data-r2dbc#368) which needs some harmonisation in the auto-configuration as well.
The text was updated successfully, but these errors were encountered:
I found something that's potentially annoying. There are a number of places where we use the DatabaseClient and the ConnectionFactory. The latter is used to fetch the dialect to use.
At the moment we inject a ConnectionFactory and we create a DatabaseClient that we reuse down the road and we back-off if a DatabaseClient is already created. This reduces the chances that the ConnectionFactory and the DatabaseClient bean do not match.
With the split, this creation is totally separated and independent of Spring Data so the bits that need to get the dialect are using the ConnectionFactory but we have no guarantee that it matches the DatabaseClient bean.
DatabaseClient that is used with R2dbcEntityOperations must be configured to match the desired database system. We have a similar arrangement with Spring Data JDBC. If a Datasource points to e.g. MySQL but the dialect is Postgres, then the configuration will not work.
Uh oh!
There was an error while loading. Please reload this page.
As of Spring Framework 5.3, the core framework has some dedicated r2dbc support. This has an impact on
spring-data-r2dbc
(see spring-projects/spring-data-r2dbc#368) which needs some harmonisation in the auto-configuration as well.The text was updated successfully, but these errors were encountered: