[
https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577939#action_12577939
]
V.Narayanan commented on DERBY-3523:
------------------------------------
>I don't think adding information about specific sql states StandardException
>is a good idea.
Sorry about the ambiguity in the previous comment. I did not mean to ask you to
push this specific
SQLState creation into StandardException.
If you were to following my suggestion you would have one method in
StandardException whose
"first three" parameters would probably be (String SQLState1, String SQLState2,
<type of upgrade>).
In the simplest case You could choose the type of upgrade to be a boolean
called hardupgrade, where
it being,
false - would indicate that SQLState1 is to be used
true - would indicate that SQLState2 is to be used
In the above case you would be retaining the logic for determining if it is a
hard or a soft upgrade
in the calling method.
You could even decide on pushing the type of upgrade deciding logic into
StandardException based on
if you think it would be appropriate.
Ofcourse I must say I do agree with
"StanduardException does very specialized job of creating SQLException and
filling it with SQLState and messages.
IMO Its better if we don't add too many functionality to it."
you have a strong case and your argument does leave me in a dilemna as to what
would be most appropriate here.
Sorry about the confusion,
<Narayanan tells himself not to write comments on JIRA issues when it is past
bed-time :( >
> sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are
> associated with wrong message texts
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3523
> URL: https://issues.apache.org/jira/browse/DERBY-3523
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.4.0.0, 10.5.0.0
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>
> There are three messages which after Derby-3330 checkin now giving wrong
> information. These are
> 42831:'{0}' cannot be a column of a primary key or unique key because it can
> contain null values.
> 42Z20:Column '{0}' cannot be made nullable. It is part of a primary key or
> unique constraint, which cannot have any null able columns.
> X0Y63.S:The command on table '{0}' failed because null data was found in the
> primary key or unique constraint/index column(s). All columns in a primary or
> unique index key must not be null.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
