Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Wed, 12 Mar 2008 14:16:44 +0530
From: Narayanan <V.Narayanan@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
In-reply-to: <47D7958D.8030103@sun.com>
Sender: V.Narayanan@Sun.COM
To: derby-dev@db.apache.org
Message-id: <47D79874.8020603@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 8BIT
References: <1029952538.1205309806538.JavaMail.jira@brutus>
 <47D7958D.8030103@sun.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)

A general tip

a reply to a mail generated by a JIRA comment, is appended to the issue 
if the 'to' in the email messages
contain

jira@apache.org

I think our email clients automatically replace the 'to' field with 
derby-dev@db.apache.org

Narayanan

Anurag Shekhar wrote:
> 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.
>
> anurag
> 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_UNIQUE_OR_PRIMARY_KEY_ON_NULL_COLS = "42831.S.1";
>>>> 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: 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.
>>>     
>>
>>   
>