I will create a separate issue for it. Even though the amount
of code changes will be very small it will end breaking several
tests (relying on either state or message).
anurag
Mike Matrigali wrote:
I have not looked at code so not sure how hard to determine which
error to throw, but seems like you should add a new error message for
the new code to use, and soft upgrade can continue to use
the old message. This is assuming there is no SQL standard for this
exact error number.
Anurag Shekhar (JIRA) wrote:
[
https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576311#action_12576311
]
Anurag Shekhar commented on DERBY-3456:
---------------------------------------
This error message is thrown while setting a unique constraint
column to null able in soft upgrade mode.
In one of the two instances (soft upgrade or regular run) message
will be wrong. Changed message will give a wrong info in soft upgrade
mode claiming that user was trying to modify a column from primary key
when he is actually modifying the constraint.
Is it ok to return wrong info in soft upgrade mode ? Probably we can
mention it in release note that in case of soft upgrade mode a wrong
info will be thrown.
Allow removing not null from collumns particpating in unique
constraint.
------------------------------------------------------------------------
Key: DERBY-3456
URL: https://issues.apache.org/jira/browse/DERBY-3456
Project: Derby
Issue Type: Sub-task
Components: SQL, Store
Affects Versions: 10.4.0.0
Environment: all
Reporter: Anurag Shekhar
Assignee: Anurag Shekhar
Attachments: altertable.diff, derby-3456-Tests.diff,
derby-3456-Tests_v2.diff, derby-3456v1.diff, derby-3456v2.diff,
derby-3456v3.diff, derby-3456v4.diff, derby-3456v5.diff,
setnulltest.diff, upgradetests.diff, upgradetests_v2.diff
Enable alter table to change a column that participates in a unique
constraint to allow nulls.
