Skip to content
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

Subclass DataIntegrityViolationException to represent main constraint types and translate SQL exceptons into appropriate subclass [SPR-2977] #7663

Closed
spring-projects-issues opened this issue Dec 23, 2006 · 4 comments
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 Dec 23, 2006

Oleksandr Alesinskyy opened SPR-2977 and commented

To the moment any SQL constraint violation exception is translated into generic DataIntegrityViolationException. It would be nice to have special subclasses for different constraint types - uniqueness violation, referential integrity violation, check violation (check constraint imposes restriction on fields of the same record). This conception is mostly rlational, but, first of all, most of databases in use are relational, and, secondly, at least conception of uniqueness and check are applicable to another database types. Referential integrity often may be interpreted in some way for non-relational databases as well.

Unlike inclusion of constraint name, which is almost impossible for techical reasons (different DBMS represent them in different ways), inclusion of constraint type shall be more or less straitforward, as virtually all DBMS report them by different values of sql error code/sql state. These values are more or less standartized, while there are several flavours.

There is a good reason to implement this functionality - constraint violation errors ususally are not fatal, application may recover (alone or with user interaction) . Direct analyse of SQL error code by application will make application too dependent on specific DB, so this translation will be of great use.

Regards,
Oleksandr


Affects: 2.0.1

Issue Links:

3 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

Oleksandr Alesinskyy commented

Any progress on this issue?

@spring-projects-issues
Copy link
Collaborator Author

Rick Evans commented

Sounds like a good enhancement to me.

+1

I have voted for it... Thomas (Risberg) and Juergen are the arbiters of the Spring data access modules though, so hopefully my commenting on this issue and bumping it to the top of the most recently updated list will get some comment.

Cheers
Rick

@spring-projects-issues
Copy link
Collaborator Author

spring-projects-issues commented Mar 25, 2009

Thomas Risberg commented

Partially resolved in #9798 Add DuplicateKeyException to DAO exception hierachy

Did not include separate check constraint exception since I did not see great value in this as a separate exception class.

@spring-projects-issues
Copy link
Collaborator Author

Oleksandr Alesinskyy commented

And what for referential integrity- it definitely deserves a separate class as in many cases application can perform some alternative actions.

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

1 participant