You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
The text was updated successfully, but these errors were encountered: