Skip to content
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.

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

Allow reuse of database error code translation without referring to JDBC module [SPR-17618] #22150

spring-projects-issues opened this issue Dec 21, 2018 · 1 comment
in: data status: declined type: enhancement


Copy link

@spring-projects-issues spring-projects-issues commented Dec 21, 2018

Oliver Drotbohm opened SPR-17618 and commented

The error code based creation of DataAccessException instances in spring-jdbc would be very useful to reuse from within Spring Data R2DBC. We'd like to avoid dragging in JDBC as it's somewhat competing technology and especially with Boot enabling features through classpath inspection we'd like to avoid having to have spring-jdbc on the classpath.

Issue Links:

  • #21996 Remove java.sql dependencies from ReflectionUtils and TransactionDefinition
Copy link

@jhoeller jhoeller commented Feb 4, 2019

As per our discussion on Friday, it seems preferable to build some error state detection into R2DBC itself or at least into Spring Data R2DBC. Our existing error code based mechanism in the JDBC module is highly JDBC-specific and mostly legacy, since the essential states are also detectable via JDBC 4 SQLException subclass analysis (our fallback step if we don't have an explicit error code match). At this point, the error code mechanism is primarily there for user extensions (i.e. a custom sql-error-codes.xml file)... and those extensions are partially JDBC-specific, since a SQLErrorCodes instance allows for a custom SQLExceptionTranslator entries per database and SQLExceptionTranslator itself deals with the JDBC java.sql.SQLException type. Avoiding a dependency on the spring.jdbc module while keeping a dependency on the java.sql module seems odd in a JDK 9+ environment, so I'd recommend a R2DBC-specific mechanism without any such dependencies instead, ideally with the error state indications coming from the R2DBC driver itself (along the lines of the SQLException subclass model in JDBC 4 drivers, rather than externally duplicating the vendor-specific error code information once again).

@jhoeller jhoeller closed this as completed Feb 4, 2019
@jhoeller jhoeller removed this from the 5.2 M1 milestone Feb 11, 2019
@jhoeller jhoeller added the status: declined label Feb 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: data status: declined type: enhancement
None yet

No branches or pull requests

2 participants