db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V.Narayanan (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
Date Fri, 14 Mar 2008 00:55:24 GMT

    [ 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.


Mime
View raw message