db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anurag Shekhar <Anurag.Shek...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-3523) sql states (X0Y63, X0Y63, X0Y63.S) related to nulls in unique constraints are associated with wrong message texts
Date Wed, 12 Mar 2008 08:34:21 GMT
thanks every one for pitching.
Let me try to summarize it

Derby doesn;t directly supports choosing message based on
the type of run (soft upgrade more or a regular mode), but it
 does allow associating multiple messages to a single sql state
bye adding "." extension (sqlstate.1, sqltate.2 etc).
 From the code this can be used to throw correct error message
after detecting the mode engine is running under (use existing sql
states during soft upgrade and newer once during regular operation).

The extensions of the sql state is dropped while setting the sql
state to SQLException so user won't experience any difference
during soft upgrade and will get newer message with same sql state
during regular operation.

Jørgen Løland (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750
> Jørgen Løland commented on DERBY-3523:
> --------------------------------------
> (Attaching mail thread)
> Narayanan wrote:
>> Jørgen Løland wrote:
>>> Mike Matrigali wrote:
>>>> It does seem like the best case would be for the error message 
>>> system to
>>>> somehow return a different error message for the same number if it is
>>>> in soft upgrade vs. hard upgrade.  Does the error message system 
>>> support
>>>> such a thing?
>>> Yes, it does. If you want multiple messages with the same SQL state, 
>>> you need to add the ".<severity>.<#>" information to the error state

>>> in SQLState.java. E.g, all these messages have SQL State 08004:
>>> ----- snip from SQLState.java ----
>>> String LOGIN_FAILED = "08004";
>>> String NET_CONNECT_AUTH_FAILED                          = "08004.C.1";
>>> String NET_DATABASE_NOT_FOUND                           = "08004.C.2";
>>> String AUTH_DATABASE_CONNECTION_REFUSED                 = "08004.C.3";
>>> String AUTH_SHUTDOWN_NOT_DB_OWNER                       = "08004.C.4";
>>> String AUTH_ENCRYPT_NOT_DB_OWNER                        = "08004.C.5";
>>> ...
>>> ----- snip -------
>>> If, e.g., both these messages
>>> '{0}' cannot be a column of a primary key or unique key because it can 
>>> contain null values.
>>> '{0}' cannot be a column of a primary key because it can contain null 
>>> values.
>>> ... should have the same 42831 error code, you would need something 
>>> like this in the SQLState.java file:
>>> String LANG_DB2_ADD_PRIMARY_KEY_ON_NULL_COLS = "42831.S.2";
>>> 'S' because 42831 is statement severity level (see class javadoc in 
>>> SQLState.java), while 1 and 2 are used to tell the messages apart. 
>>> messages.xml also needs to be updated, of course.
>> But how will this  help in printing different error messages in hard and 
>> soft upgrade? I thought this would be useful
>> in grouping together the same family of messages, but can this act as a 
>> switch for messages that need to be printed
>> in hard and soft upgrade?
>> Narayanan
> The code where these exceptions are thrown needs to explicitly use the correct exception.
However, this is the same thing that must be done if fix suggestion 2 is chosen. 
> I think suggestion 2 should be modified like this:
> 2b: Introduce new message without changing the state and use old messages only during
soft upgrade run.
>> 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:,
>>            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.

View raw message