db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anurag Shekhar (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3330) provide support for unique constraint over keys that include one or more nullable columns.
Date Wed, 05 Mar 2008 17:59:40 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575436#action_12575436

Anurag Shekhar commented on DERBY-3330:

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.

This piece of code is unnecessary. I had added it initially for some debugging
 purpose and forgot to remove.  Sorry about it. I will take it off.

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;

I will add comment in my follow up patch and will also check how can I make sort 
independent of information about location.

    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)

It shouldn't return from this code but should set 
return value to ConglomerateController.ROWISDUPLICATE, so that necessary cleanup of latch
 is performed. 

    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.

It looks good. Its exact description of what will happen during soft 
and hard upgrade. Thanks a lot for adding this.

    Should change following to match new naming:
    sb.append ("ALMOST UNIQUE");

I will change this.

    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) &&

This should be checking for uniqueWithDuplicateNull. I will update it.

    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 will go though the code and try to identify the problem areas.

I don't see upgrade tests, are they in a different JIRA/patch?

I have attached tests in derby-3330-UpgradeTests.diff

I am working on the followup patch and will upload it asap.

> 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:
>         Environment: all
>            Reporter: Anurag Shekhar
>            Assignee: Anurag Shekhar
>         Attachments: BTreeController.diff, db2Compatibility-v2.diff, db2Compatibility.diff,
derby-3330-testcase.diff, derby-3330-UpgradeTests.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.

View raw message