[
https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12578555#action_12578555
]
narayanan edited comment on DERBY-3523 at 3/13/08 5:53 PM:
-------------------------------------------------------------
>The new method in StandardException seems a little overkill for what really
>could be a ? : operator in the calling code.
> String sqlState = checkVersion(....) ? SQLState.XXX : SQLState.YYY;
> If the method is to be kept, it might be clearer to have its name reflect
> what it is doing.
I agree that using ? : would be a better way of implementing this and also that
the name of the method
could probably be changed to reflect what it is doing.
But I do not agree that it is overkill to factor out logic to choose a SQLState
based on whether it is soft or
hard upgrade.
Why would it be wrong to put in a utility method in StandardException that
chooses one of the two
SQLStates based on a boolean if a valid case for its usage could be justified
(e.g. choosing one
based on if it is hard or soft upgrade) ?
This is not a case that is specific to the class using this logic but a generic
case that could
occur in multiple parts of the codebase.
was (Author: narayanan):
>The new method in StandardException seems a little overkill for what
really could be a ? : operator in the calling code.
> String sqlState = checkVersion(....) ? SQLState.XXX : SQLState.YYY;
> If the method is to be kept, it might be clearer to have its name reflect
> what it is doing.
I agree that using ? : would be a better way of implementing this and also that
the name of the method
could probably be changed to reflect what it is doing.
But I do not agree that it is overkill to factor out logic to choose a SQLState
based on whether it is soft or
hard upgrade.
Why would it be wrong to put in a utility method in StandardException that
chooses one of the two
SQLStates based on a boolean if a valid case for its usage could be justified
(e.g. choosing one
based on if it is hard or soft upgrade) ?
This is not a case that is specific to the class using this logic but a generic
case that could
occur in multiple parts of the code.
> 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
> Attachments: derby-3523v1.diff, derby-3523v2.diff
>
>
> 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.
