GH-2031 Introduced new JDBC dialect counterparts #2036
Conversation
spring-projects-issues
added
the
status: waiting-for-triage
| @@ -109,23 +111,23 @@ public Optional<Dialect> getDialect(JdbcOperations operations) { | |||
| } | |||
|
|
|||
| @Nullable | |||
| private static Dialect getDialect(Connection connection) throws SQLException { | |||
| private static JdbcDialect getDialect(Connection connection) throws SQLException { | |||
There was a problem hiding this comment.
So, here I am not sure what is the best solution. Let me clarify. The JdbcDialectProvider interface is defined like this:
public interface JdbcDialectProvider {
Optional<Dialect> getDialect(JdbcOperations operations);
}
The common sense dictates, that since it is a DialectProvider for JDBC, then the returned dialect is supposed to be an instance of JdbcDialect. However, such type migration change would not be backward compatible.
The solution I can think of is to deprecate this method in the interface, and maybe even make JdbcDialectProvider a top-level interface, instead of being an inner one. And in this case, we can direct users to a new interface to be used, where getDialect method returns the Optional<JdbcDialect>
If we just deprecate the JdbcDialectProvider#getDialect method, we will not be able to say at the moment what is the replacement.
Maybe I'm just overcomplicating things... I need your option, Mark @mp911de
Signed-off-by: mipo256 <[email protected]>
Closes #2031
The idea is to introduce for each relational
Dialectits jdbc counterpart. All the Jdbc dialects that were already in place (there were a couple of those) and added ones now extend theJdbcDialectand their corresponding relational counterpart.CC: @mp911de @schauder