David Lopez opened DATAJDBC-611 and commented
When inserting a new entity which would result on a violation of a UNIQUE key into the database using the default implementation of the save() method of the repository, the call ends raising a DbActionExecutionException instead of a DataAccessException.
More specifically, the call to the NamedParameterJdbcTemplate, invoked from the insert() method of the DefaultDataAccessStrategy, raised a DuplicateKeyException as result of a SQLIntegrityConstraintViolationException generated by the driver. So far so good.
However, this exception is caught at the AggregateChangeExecutor::execute() method and encapsulated into a DbActionExecutionException.
Whereas this seems correct, as this exception provides more information than the original DataAccessException, the fact that a @Repository method is returning this exception instead of DataAccessException one is, IMHO, a violation of the Consistent Exception Hierarchy core principles followed by all the Spring Data subprojects, as stated on its own documentation (Reference Documentation).
For instance, the behaviour of Spring Data JPA is different in this same scenario, raising a DataIntegrityViolationException mapped from a Hibernate exception.
In my project, I fixed this situation defining a PersistenceExceptionTranslator bean
AFAIK, no translator is provided by Spring Data JDBC, as it is based on Spring JDBC, but the use of DbActionExecutionException results on a violation of one of the core principles, at least on this case.
No further details from DATAJDBC-611
David Lopez opened DATAJDBC-611 and commented
When inserting a new entity which would result on a violation of a UNIQUE key into the database using the default implementation of the
save()method of the repository, the call ends raising aDbActionExecutionExceptioninstead of aDataAccessException.More specifically, the call to the
NamedParameterJdbcTemplate, invoked from theinsert()method of theDefaultDataAccessStrategy, raised aDuplicateKeyExceptionas result of aSQLIntegrityConstraintViolationExceptiongenerated by the driver. So far so good.However, this exception is caught at the
AggregateChangeExecutor::execute()method and encapsulated into aDbActionExecutionException.Whereas this seems correct, as this exception provides more information than the original
DataAccessException, the fact that a@Repositorymethod is returning this exception instead ofDataAccessExceptionone is, IMHO, a violation of the Consistent Exception Hierarchy core principles followed by all the Spring Data subprojects, as stated on its own documentation (Reference Documentation).For instance, the behaviour of Spring Data JPA is different in this same scenario, raising a
DataIntegrityViolationExceptionmapped from a Hibernate exception.In my project, I fixed this situation defining a
PersistenceExceptionTranslatorbeanAFAIK, no translator is provided by Spring Data JDBC, as it is based on Spring JDBC, but the use of
DbActionExecutionExceptionresults on a violation of one of the core principles, at least on this case.No further details from DATAJDBC-611