-
Notifications
You must be signed in to change notification settings - Fork 358
save() method is raising a DbActionExecutionException on unique key violation [DATAJDBC-611] #831
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
Comments
schauder
pushed a commit
that referenced
this issue
Mar 17, 2025
We now raise the exceptions from `NamedParameterJdbcTemplate` directly. If you used to extract the `cause` of a `DbActionExecutionException` you should now catch that Exception directly. Original pull request #1956 Closes #831 Signed-off-by: mipo256 <[email protected]>
schauder
pushed a commit
that referenced
this issue
Apr 10, 2025
We now raise the exceptions from `NamedParameterJdbcTemplate` directly. If you used to extract the `cause` of a `DbActionExecutionException` you should now catch that Exception directly. Original pull request #1956 Closes #831 Signed-off-by: mipo256 <[email protected]>
schauder
pushed a commit
that referenced
this issue
Apr 25, 2025
We now raise the exceptions from `NamedParameterJdbcTemplate` directly. If you used to extract the `cause` of a `DbActionExecutionException` you should now catch that Exception directly. Original pull request #1956 Closes #831 Signed-off-by: mipo256 <[email protected]>
schauder
pushed a commit
that referenced
this issue
May 12, 2025
We now raise the exceptions from `NamedParameterJdbcTemplate` directly. If you used to extract the `cause` of a `DbActionExecutionException` you should now catch that Exception directly. Original pull request #1956 Closes #831 Signed-off-by: mipo256 <[email protected]>
mp911de
pushed a commit
that referenced
this issue
May 16, 2025
We now raise the exceptions from `NamedParameterJdbcTemplate` directly. If you used to extract the `cause` of a `DbActionExecutionException` you should now catch that Exception directly. Original pull request #1956 Closes #831 Signed-off-by: mipo256 <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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 aDbActionExecutionException
instead of aDataAccessException
.More specifically, the call to the
NamedParameterJdbcTemplate
, invoked from theinsert()
method of theDefaultDataAccessStrategy
, raised aDuplicateKeyException
as result of aSQLIntegrityConstraintViolationException
generated 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@Repository
method is returning this exception instead ofDataAccessException
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
beanAFAIK, 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
The text was updated successfully, but these errors were encountered: