[
https://issues.apache.org/jira/browse/DERBY-6773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14502027#comment-14502027
]
Bryan Pendleton commented on DERBY-6773:
----------------------------------------
I spent some time digging into Sqlca.getMessage(), to understand better how
it operates. I recorded what I learned in a comment on DERBY-1178, which
seemed like a relevant place to keep this information. The core finding is that,
although the client does indeed have access to the message arguments, the
arguments are encoded in a format which is currently implemented entirely
be the server. That is, the format of the encoding of the message arguments
is not currently "shared" knowledge between the client and the server, so the
client doesn't trivially have the arguments in a simple array which it could use
to pluck out the table name and constraint name cleanly.
It seems to me that we could, potentially, refactor the server's argument
encoding/decoding
logic from the places such as org.apache.derby.iapi.services.i18n.MessageService
where it currently resides, and put it into something like
org.apache.derby.shared.common.error.MessageUtils
so that both server and client could manipulate the encode message arguments
in a fairly clean fashion.
I think that we might consider making that a separable sub-project of this
overall
effort, and create a new sub-task for it.
Abhinav, what do you think about this idea? Does it make sense?
> 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,
> generateOnClientDoesntWork.diff
>
>
> 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)
