[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-3330:
----------------------------------
Derby Info: [Patch Available, Release Note Needed] (was: [Release Note
Needed, Patch Available])
Here are some comments that were still unresolved in the submitted patch, but
didn't seem big enough to hold up the patch and can be addressed with a
subsequent patch.
CreateIndexConstantAction.java -
use of properties? Some of the existing code seems to sometimes expect
a properties passed in. Your new code will overwrite the saved copy of
the properties to pass needed info to the new sort routine. I don't
know when a property may be passed in and lost. I think you just want
to create a new variable for sort_properties.
sort changes
I don't like that the implementation of unique merge sort knows about
row location last column. The intent of the sorted is to be somewhat
general purpose so it would be better to somehow encode that info into
the startup parameters. I think the null special handling is located
in the right place, ie. in the new sort impl.
A comment explaining the why of these 2 lines would be nice in
UniqueWithDuplicateNullMergeSort.java would be nice.
if (i == colsToCompare - 1 && nonull)
return 0;
BTreeController.java
Can the second call to the following code be optimized, is it necessary?
maybe a comment here would help.
if (getConglomerate().isUniqueWithDuplicateNulls()) {
int ret = compareLeftAndRightSiblings(rowToInsert,
insert_slot, targetleaf);
if (ret == MATCH_FOUND)
return ConglomerateController.ROWISDUPLICATE;
if (ret == RESCAN_REQUIRED)
continue;
}
B2I.java
I updated the upgrade comments, especially for the change in behavior for
the 10.3 formats. You should review these to make sure they are what
you expect.
IndexDescriptorImpl.java
Should change following to match new naming:
sb.append ("ALMOST UNIQUE");
The following is a wrong (repeated same test), but I didn't change -
wanted to give you a chance to look at it. Not sure what it affects, if
it is a bug would be nice to have a test case that shows the problem.
Wasn't sure if it wanted another different term, probably wants to be a
test for the new attribute.
if ((id.isUnique == this.isUnique) &&
(id.isUnique == this.isUnique) &&
BTreeController.java
I think there may be some edge case stuff missing from the searches, I
will look more later, but it looks like a good basis for the new
functionality so rather see it get checked in and more eyes on it.
Again now that new searches only happen on new nullable constraints there
is less risk to existing functionality.
I don't see upgrade tests, are they in a different JIRA/patch?
> provide support for unique constraint over keys that include one or more
> nullable columns.
> ------------------------------------------------------------------------------------------
>
> Key: DERBY-3330
> URL: https://issues.apache.org/jira/browse/DERBY-3330
> Project: Derby
> Issue Type: New Feature
> Components: Store
> Affects Versions: 10.4.0.0
> Environment: all
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
> Attachments: BTreeController.diff, db2Compatibility-v2.diff,
> db2Compatibility.diff, derby-3330-testcase.diff, derby-3330.diff,
> derby-3330v10.diff, derby-3330v11.diff, derby-3330v12.diff,
> derby-3330v13.diff, derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,
> derby-3330v5.diff, derby-3330v6.diff, derby-3330v7.diff, derby-3330v8.diff,
> derby-3330v9.diff, derbyall_report.txt, FunctionalSpec_DERBY-3330-V2.html,
> FunctionalSpec_DERBY-3330.html, UniqueConstraint_Implementation.html,
> UniqueConstraint_Implementation_V2.html,
> UniqueConstraint_Implementation_V3.html
>
>
> Allow unique constraint over keys which include one or more nullable fields.
> Prior to this change Derby only supported unique constraints on keys that
> included no nullable columns. The new constraint will allow unlimited
> inserts of any key with one more null columns, but will limit insert of keys
> with no null columns to 1 unique value per table.
> There is no change to existing or newly created unique indexes on null
> columns (as opposed to unique constraints on null columns). Also there is no
> change to existing or newly created constraints on keys with no nullable
> columns.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
