db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Pendleton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6773) Derby throws plain SQLIntegrityConstraintViolationException
Date Mon, 02 Mar 2015 22:41:04 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343922#comment-14343922

Bryan Pendleton commented on DERBY-6773:

I think you have exactly the right idea about the approach to the fix.

The constraint name and table name are held in the StandardException object,
in the "arguments" array. You can see the constraint name and table name
being associated with the StandardException at line 592 of

                        StandardException se =
                                SQLState.LANG_DUPLICATE_KEY_CONSTRAINT, indexOrConstraintName,
                        throw se;

And at line 233 of org.apache.derby.impl.jdbc.Util.java we have the
StandardException and we are using it to create the SQLException:

        public static SQLException generateCsSQLException(StandardException se)
        return ExceptionFactory.getInstance().getSQLException(
                se.getMessage(), se.getMessageId(), (SQLException) null,
                se.getSeverity(), se, se.getArguments());

So it would seem that we can access the arguments to learn the constraint
name and table name and pass them to the new SQLException subclass that
we wish to create.

I think we will also have to pay attention to the complications described in DERBY-1178, though.

Hmmm... this is turning into a larger project than I was hoping it would.

Still, it would be very interesting to see if you can just create a new exception
subclass instance, in SQLExceptionFactory.java, and pass it the constraint name and
table name from the arguments.

Something along the idea of this:

Index: SQLExceptionFactory.java
--- SQLExceptionFactory.java    (revision 1662607)
+++ SQLExceptionFactory.java    (working copy)
@@ -82,8 +82,8 @@
         } else if (sqlState.startsWith(SQLState.SQL_DATA_PREFIX)) {
             ex = new SQLDataException(message, sqlState, severity, ferry);
         } else if (sqlState.startsWith(SQLState.INTEGRITY_VIOLATION_PREFIX)) {
-            ex = new SQLIntegrityConstraintViolationException(message, sqlState,
-                    severity, ferry);
+            ex = new DerbySQLIntegrityConstraintViolationException(message, sqlState,
+                    severity, ferry, args[0], args[1]);
         } else if (sqlState.startsWith(SQLState.AUTHORIZATION_SPEC_PREFIX)) {
             ex = new SQLInvalidAuthorizationSpecException(message, sqlState,
                     severity, ferry);

> Derby throws plain SQLIntegrityConstraintViolationException
> -----------------------------------------------------------
>                 Key: DERBY-6773
>                 URL: https://issues.apache.org/jira/browse/DERBY-6773
>             Project: Derby
>          Issue Type: Improvement
>          Components: JDBC
>    Affects Versions:
>         Environment: Windows 7 x86_64, Java
>            Reporter: Jochen Wiedmann
>            Assignee: Abhinav Gupta
>            Priority: Minor
>         Attachments: DERBY6733Repro.java
> If a unique constraint is violated by an insert statement, then Derby throws an SQLIntegrityConstraintViolationException.
The error message contains, in particular, the constraint name and the table name.
> To distinguish between cases with various constraints, Derby should instead throw a subclass
of SQLIntegrityConstraintViolationException, with methods like getConstraintName(), and getTableName().
> See also https://hibernate.atlassian.net/browse/HHH-9516.

This message was sent by Atlassian JIRA

View raw message