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

[spring-issuemaster]

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

[jhoeller]

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).