-
Notifications
You must be signed in to change notification settings - Fork 38.4k
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
Duplicate key violation gets translated to DataIntegrityViolationException instead of DuplicateKeyException in Spring 6 #29511
Comments
This is to be expected due to the switch to using See: If you absolutely need to differentiate between For example: DataSource dataSource = ...
JdbcTemplate jdbcTemplate = new JdbcTemplate(dataSource);
jdbcTemplate.setExceptionTranslator(new SQLErrorCodeSQLExceptionTranslator(dataSource));
jdbcTemplate.afterPropertiesSet(); In light of the above, I am closing this issue as "works as designed"; however, I have also created #29518 to update the Upgrading to Spring Framework 6.x wiki page. |
Hi @sbrannen, I cannot set anything on Thanks a lot. |
Understood.
Technically speaking it is indeed a regression in the default behavior, but there are ways to get the old behavior back (the one I mentioned previously and one that I'll mention below).
I believe you should be able to introduce an empty If neither of these options works for you, please post back here, and we will continue the discussion. |
Fixed adding the following "empty" <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN 2.0//EN" "https://www.springframework.org/dtd/spring-beans-2.0.dtd">
<beans /> Thank you again. |
As a library author, I can't use any of the mentioned workarounds |
Reopening to improve documentation. See #29673 (comment) |
As a documentation issue for the default exception translator change in 6.0, we should highlight That said, if these turn out to be common enough scenarios, we can try to make |
It turns out that all databases that I checked support 23505 as a common SQL state value for duplicate keys, within the general 23xxx range that indicates data integrity violations. I'm therefore adding a specific 23505 check to Of course, re-enabling the From the perspective above, I'm turning this ticket into a regression issue that we will address in the 6.0.3 release, also documenting the general default change and its potential impact a bit better in the upgrade notes. |
Hi, the fix did not help with confilct on insert. In MariaDb, MySQL, MS SQL and Oracle the SQL state is 23000. |
@lukas-krecan, this issue is closed, and the changes have already been released in Spring Framework 6.0.3. Please create a new issue to discuss the "conflict on insert". Thanks |
Affects: 6.0.0
Hi, I just upgraded from 5.3.24 to 6.0.0 and noticed a different behaviour of Spring JDBC/TX. I have a class containing simple JDBC statements executed with
JdbcTemplate
(no JPA, no ORMs), and I wrote some test cases based on H2.In case of duplicate key errors, I expect
DuplicateKeyException
, but after the upgrade I'm getting a more genericDataIntegrityViolationException
(that obviously breaks the test):Looking into the sources, I noticed that v5 instantiates a
DuplicateKeyException
inSQLErrorCodeSQLExceptionTranslator
while v6 instantiates aDataIntegrityViolationException
inSQLExceptionSubclassTranslator
.Thank you.
The text was updated successfully, but these errors were encountered: