[
https://issues.apache.org/jira/browse/DERBY-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14708152#comment-14708152
]
Bryan Pendleton commented on DERBY-6779:
----------------------------------------
Now that DERBY-6773 is complete, this would be a straightforward enhancement:
1) Define a new exception class: DerbyDuplicateKeyConstraintViolationException
which is a
subclass of DerbySQLIntegrityConstraintViolationException
2) Change the client and server SQLExceptionFactory code to throw the new
exception
based on the SQL state being one of LANG_DUPLICATE_KEY_CONSTRAINT,
LANG_DEFERRED_DUPLICATE_KEY_CONSTRAINT_S, or
LANG_DEFERRED_DUPLICATE_KEY_CONSTRAINT_T
3) Add new test cases to, say, ConstraintCharacteristicsTest and
ForeignKeysDeferrableTest, to verify the new behavior.
However, as was mentioned on the mailing list discussions referenced above, it's
not clear how much value this really adds, since the SQLState in the exception
already allows applications to tell that this is a duplicate key exception.
> Provide subclass of SQLException for duplicate key insertions
> -------------------------------------------------------------
>
> Key: DERBY-6779
> URL: https://issues.apache.org/jira/browse/DERBY-6779
> Project: Derby
> Issue Type: Improvement
> Components: JDBC, SQL
> Reporter: John English
> Priority: Minor
>
> A commonly-occurring situation is to take some special action when an insert
> fails due to a duplicate key; for example, to update the existing row or to
> retry the insert with a new key (e.g. mutate "Name" into "Name(1)", "Name(2)"
> etc. until a unique key is found). At present this requires code similar to:
> {noformat}
> try {
> //... insert new row
> }
> catch (SQLException e) {
> if (e.getSQLState().equals(DUPLICATE_KEY)) {
> // ... take recovery action
> }
> else {
> throw e;
> }
> }
> {noformat}
> It would be more convenient if a subclass of SQLException were used to report
> this precise error. The SQLIntegrityConstraintViolationException that is
> currently thrown will also be thrown in other case where a constraint is
> violated. A new exception subclass for this specific situation would not
> affect any existing code, and would allow the code above to be simplified to
> this:
> {noformat}
> try {
> //... insert new row
> }
> catch (DuplicateKeyException e) { // or some other suitable name
> // ... take recovery action
> }
> {noformat}
> This would allow a more elegant, more O-O solution to what is, in my
> experience, a common use case without having to discriminate based on the
> value of getSQLState().
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
