ClickHouse provides an r2dbc driver. Building a project with Testcontainers fails because of the following exception:
Caused by: org.springframework.r2dbc.core.binding.BindMarkersFactoryResolver$NoBindMarkersFactoryException: Cannot determine a BindMarkersFactory for ClickHouse using ConnectionPool[ClickHouse]
Add ClickHouse to the list https://github.com/spring-projects/spring-framework/blob/5e08a88219dd5aaa2f3a3bf4ff36c7b2bcd6ed37/spring-r2dbc/src/main/java/org/springframework/r2dbc/core/binding/BindMarkersFactoryResolver.java#L119-L128
My workaround was to created my own provider and register it in spring.factories but it fails because it also needs to support the ClickHouse dialect in spring-data-r2dbc.
Comment From: sdeleuze
@eddumelendez I can probably perform related refinements to unlock future progresses on spring-data-r2dbc side. Just we need to decide which version we target. If you can submit a PR short term on Spring Data side, let's target Spring Framework 6.2, otherwise 7.0. Could you please share your timeline on Spring Data side?
Comment From: spring-projects-issues
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Comment From: eddumelendez
Hi @sdeleuze, sorry for the delay. I can contribute to the spring-data-relational project by the end of the week. However, the issue there was closed because of team capacity and there is a comment in another PR adding a new dialect for the same reason.
Comment From: sdeleuze
No problem, thanks for your feedback.
@mp911de Could you please let us know what you plan to do on Spring Data side. If you plan to reconsider a related PR, we will do the change on Spring Framework side. If not, we will decline.
Comment From: mp911de
I've revisited that topic with the data team. While we would like to broaden support to provide a better dev experience using ClickHouse (i.e. not requiring folks to provide their own config), we are in a situation where we cannot afford to fully maintain another database because of bandwidth on our side. We're barely able to fix some selected bugs.
Another aspect plays into this as well. Having only a R2DBC dialect would be a simpler option than integrating the JDBC side because R2DBC has a smaller feature set. However, if we want to support ClickHouse, it would be required to do the same for the JDBC integration, which is much more complex. ClickHouse comes with all sorts of data types that require proper integration on our side. With that outlook, we have to expect additional feature requests that we would not be able to handle properly resulting in supporting partial database support that is not suitable for modern application usage.
If there is sufficient ask for ClickHouse in the community to run on Spring, I suggest that ClickHouse would host a repository and ship binaries providing the configuration for Framework and Spring Data in the form of dialects and binding markers built on top of already existing SPI.
Comment From: sdeleuze
Thanks @mp911de for the detailed feedback, I will then decline this issue.