Description
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