[
https://issues.apache.org/jira/browse/DERBY-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577750#action_12577750
]
jorgenlo edited comment on DERBY-3523 at 3/12/08 1:17 AM:
---------------------------------------------------------------
(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
>
I misinterpreted Mike's question. 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.
was (Author: jorgenlo):
(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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
