Skip to content

HibernateJpaDialect cannot translate JDBCException to custom DataAccessException [SPR-17015] #21553

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

Closed
spring-projects-issues opened this issue Jul 6, 2018 · 3 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Jul 6, 2018

Joram Agten opened SPR-17015 and commented

If using both jdbc and hibernate-orm (hibernate 5) in a spring project, only jdbc translates db error codes to custom DataAccessException when configuring them in sql-error-codes.xml.
Hibernate-orm only maps to the standard set of DataAccessException.
In org.springframework.orm.hibernate3.HibernateExceptionTranslator#convertHibernateAccessException the jdbcExceptionTranslator is used.
This allows with the configuration of sql-error-codes.xml to map exceptions to custom DataAccessException 's

In org.springframework.orm.hibernate5.HibernateExceptionTranslator#convertHibernateAccessException (and also the one for hibernate4) this jdbcExceptionTranslator is no longer used.

temporary solved with attached DataAccessExceptionTranslatorHibernateJpaDialect.java
this is then configured as jpaDialect on the entityManagerFactory


Affects: 4.3.13

Attachments:

Issue Links:

Referenced from: commits d9e8d3b

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

The main reason for this is that Hibernate itself has database-specific error mappings in its dialect implementations now: see http://docs.jboss.org/hibernate/orm/5.3/javadocs/org/hibernate/dialect/Dialect.html#buildSQLExceptionConversionDelegate--

What specifically have you found missing in Hibernate's own exception translation? Could you potentially also add this to a custom Hibernate Dialect extension?

@spring-projects-issues
Copy link
Collaborator Author

Joram Agten commented

When using jdbcExceptionTranslator exceptions are translated to children of org.springframework.dao.DataAccessException
when using hibernates SQLExceptionConverter exceptions are translated to children of org.hibernate.JDBCException

If we want to map a (custom business) exception on the database to an exception in the java code we need 2 different Exception classes (since jdbc and hibernate map from different packages).
If we then want to map this (custom business) exception on the database to a client friendly message on the front end, we also need an ExceptionHandler that catches 2 different Exception classes, which makes it dependent on the way the database is accessed.

In HibernateJpaDialect some hibernate JDBCException are converted to spring DataAccessException (convertHibernateAccessException), and as fallback wrapped in JpaSystemException.
If using hibernates SQLExceptionConverter this would mean that the custom JDBCException would be wrapped in JpaSystemException.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

This is a good point indeed: In HibernateExceptionTranslator as well as HibernateJpaDialect, a custom SQLExceptionTranslator can still be useful for translating to custom exception types... even if the standard exception types are largely covered by Hibernate's own mechanism in the meantime, and even if HibernateJpaDialect never really made use of the SQLExceptionTranslator machinery in the first place (just the Hibernate 3.x HibernateExceptionTranslator and LocalSessionFactoryBean did).

For 5.1, I've added a corresponding jdbcExceptionTranslator property, allowing you to specify a custom translator which kicks in before regular JDBCException translation. This can either be a totally custom SQLExceptionTranslator implementation which just handles your custom cases and returns null otherwise (similar to a fallbackTranslator attached to a SQLErrorCodeSQLExceptionTranslator), or one of Spring's standard translators which then overrides Hibernate's regular JDBCException translation completely.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants