Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Sun, 12 Apr 2015 20:00:12 +0000 (UTC)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12757165.1416670280000.67457.1428868812694@Atlassian.JIRA>
In-Reply-To: <JIRA.12757165.1416670280000@Atlassian.JIRA>
References: <JIRA.12757165.1416670280000@Atlassian.JIRA>
 <JIRA.12757165.1416670280617@arcas>
Subject: [jira] [Commented] (DERBY-6773) Derby throws plain
 SQLIntegrityConstraintViolationException
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Bryan Pendleton commented on DERBY-6773:
----------------------------------------

I've been thinking about the client-server support, on and off, over the last month.

And I've convinced myself that the answer lies in the class
org.apache.derby.client.am.SqlException

An instance of this class is constructed by the client library when it decodes
an error message received over the DRDA protocol from the server. The
SqlException instance has access to the correct message arguments, because it
uses them to build the complete message on the client side:

    SqlException(LogWriter logwriter,
        ClientMessageId msgid, Object[] args, Throwable cause)
    {
        this(
            logwriter,
            cause,
            getMessageUtil().getCompleteMessage(
                msgid.msgid,
                args),
            ExceptionUtil.getSQLStateFromIdentifier(msgid.msgid),
            ExceptionUtil.getSeverityFromIdentifier(msgid.msgid));
    }

A little bit later, SqlException.getSQLException() gets called, to
construct the java.sql.SQLException that wraps the Derby message:

        SQLException sqle = exceptionFactory.getSQLException(getMessage(), getSQ
LState(),
            getErrorCode());
        sqle.initCause(this);

What I think we have to do is to extend these two pieces of code so that they:
a) save the "args" in the SqlException instance itself in the constructor, and
b) then pass the "args" to SqlExceptionFactory:getSQLException() so that it
    can use those args to construct a DerbySQLIntegrityConstraintViolationException
   with the right table name and constraint name taken from the args.

Then I think we'll have a complete pattern that will work for generating
Derby-specific SQLException subclasses as we desire, with the additional
information from the args made available as this JIRA issue suggests.

I'll see if I can work up a prototype patch that demonstrates this.

> 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: 10.10.2.0
>         Environment: Windows 7 x86_64, Java 1.6.0.45
>            Reporter: Jochen Wiedmann
>            Assignee: Abhinav Gupta
>            Priority: Minor
>         Attachments: CallSuper.diff, DERBY6733Repro.java, SamePackage.diff, SharedException.diff, ant -verbose build all.txt
>
>
> 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
(v6.3.4#6332)