Skip to content

Introduce JDBC-specific dialects in JDBC module #2031

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
mipo256 opened this issue Apr 16, 2025 · 6 comments · May be fixed by #2036
Open

Introduce JDBC-specific dialects in JDBC module #2031

mipo256 opened this issue Apr 16, 2025 · 6 comments · May be fixed by #2036
Labels
type: enhancement A general enhancement

Comments

@mipo256
Copy link
Contributor

mipo256 commented Apr 16, 2025 •
edited
Loading

The problem became evident while working on the following PR #2024.

We have a Dialect interface abstraction, that resides in the relational module. That makes sense, since several capabilities can be re-used in both jdbc and r2dbc modules. We then have a common dialects (that also reside in the relational module) like PostgresDialect or H2Dialect.

For r2dbc, there is no problem - we have a separate PostgresDialect class, that resides in the r2dbc (!) module, and that extends the PostgresDialect in relational module. Therefore, the r2dbc's PostgresDialect can use all the features that reside in the r2dbc module, as it should.

In case of jdbc - we have a problem. The dialects that we use in jdbc module are really placed in the relational module. That becomes a big deal, when we want (and we probably should want) to use some jdbc specific functionality (like java.sql.SQLType) in the dialect that is supposed to be used in spring-data-jdbc.

Soltuion: the way the dialecfts are now structured in r2dbc is the right way to go in my opinion, and in jdbc module we should not use the dialects in relational module, we should provide classes that extend them in the jdbc module, so we can allow these dialects to use jdbc-specific features.
@mipo256 mipo256 mentioned this issue Apr 16, 2025
Open
@mipo256
Copy link
Contributor Author

mipo256 commented Apr 16, 2025

I can take a look in here, since I'm already in the context of the problem @mp911de

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Apr 16, 2025
@schauder
Copy link
Contributor

So far we did this on a as-needed basis. See for example JdbcSqlServerDialect

We DO have an inconsistency here: R2DBC dialects have the same name as their relational counter part, while the JDBC variants have a JDBC dialect.

This is something we could unify for 4.0. i.e. creating new classes and deprecating old ones on main and removing the old ones in 4.0.x

Not sure if we always should create a JDBC variant, even when it just extends the base class.
Opinions?

@mp911de
Copy link
Member

mp911de commented Apr 16, 2025

Having a JDBC-specific subinterface and distinguishing between the R2DBC dialects makes sense. Dialect specifics make sense on the relational level when considering functionality that is dialect-specific (note: not driver-specific) such as array handling, expressing limit clauses, locks (in the SQL statement) and some more details.

R2dbcDialect considers R2DBC-specifics such as bind-markers. We can already see a need to do the same for JDBC-specifics as the SQLType business.

@mipo256
Copy link
Contributor Author

mipo256 commented Apr 16, 2025

What is the solution going to look like @schauder @mp911de ? I can think of adding dialects in the jdbc module that extend the relational counterparts along with JdbcDialect.

@schauder
Copy link
Contributor

Having a JDBC-specific subinterface and distinguishing between the R2DBC dialects makes sense. Dialect specifics make sense on the relational level when considering functionality that is dialect-specific (note: not driver-specific) such as array handling, expressing limit clauses, locks (in the SQL statement) and some more details.

R2dbcDialect considers R2DBC-specifics such as bind-markers. We can already see a need to do the same for JDBC-specifics as the SQLType business.

As written above: the JDBC specific interface already exists and so do JDBC specific implementations.

The differences to the way it is handled in R2DBC are:

  1. R2DBC seems to have jdbc specific implementations for all dialects.
  2. The naming convention: JDBC uses a JDBC prefix.

@mipo256
Copy link
Contributor Author

mipo256 commented Apr 16, 2025 •
edited
Loading

I got it, thanks @schauder, I'll submit a PR shortly

@mp911de mp911de added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Apr 17, 2025
mipo256 added a commit to mipo256/spring-data-relational that referenced this issue Apr 20, 2025
@mipo256
spring-projectsGH-2031 Introduced new JDBC dialect counterparts
034539d
mipo256 added a commit to mipo256/spring-data-relational that referenced this issue Apr 20, 2025
@mipo256
spring-projectsGH-2031 Introduced new JDBC dialect counterparts
5ffed08
@mipo256 mipo256 linked a pull request Apr 20, 2025 that will close this issue
Open
mipo256 added a commit to mipo256/spring-data-relational that referenced this issue Apr 20, 2025
@mipo256
spring-projectsGH-2031 Introduced new JDBC dialect counterparts
79b3900 
Signed-off-by: mipo256 <[email protected]>
mipo256 added a commit to mipo256/spring-data-relational that referenced this issue Apr 20, 2025
@mipo256
spring-projectsGH-2031 Introduced new JDBC dialect counterparts
413de0a 
Signed-off-by: mipo256 <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type: enhancement A general enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

GH-2031 Introduced new JDBC dialect counterparts mipo256/spring-data-relational
4 participants
@schauder @mp911de @spring-projects-issues @mipo256