Description
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:
- Add DuplicateKeyException to DAO exception hierachy [SPR-5125] #9798 Add DuplicateKeyException to DAO exception hierachy
3 votes, 2 watchers