[
https://issues.apache.org/jira/browse/DERBY-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563119#action_12563119
]
Anurag Shekhar commented on DERBY-3330:
---------------------------------------
thanks Mike for looking at the patch and detailed comments
I am explaining few points in this comment and will get back
about rest of the comments
overall:
o almost unique, doesn't seem like a good name for this. And I didn't see
good documentation in the code explaining what this means. Unfortunately
could not think of something less wordy than AllowMulipleNullsInUnique.
Shall I change it to UniqueWhenNotNull ?
o not sure what you are using for tab/spaces, see derby web site for following
existing conventions in the code. may seem minor but inconsistent tab/indent
makes stuff unreadable. Derby code that has tab indentation expects 4 spaces
for those tabs.
I will check the indentations and fix them.
o i have to think about it some more but the places you added the
if (compareLeftAndRightSiblings(rowToInsert,
insert_slot, targetleaf))
return ConglomerateController.ROWISDUPLICATE;
don't seem optimal. I would like to see the code only called in the
almost unique case, so we don't affect the behavior of existing indexes at
all.
I will change it to check for new index before calling
compareLeftAndRightSiblings.
java/engine/org/apache/derby/impl/store/access/btree/index/B2I.java
o it is critical to properly document changes to ondisk format of store objects,
doesn't look like any work here done. I know from existing comments that
upgrade still does not work so maybe you are planning more here.
o The model has been to add new stuff at the end rather than in the middle.
I will be fixing it in my new patch.
o so far I haven't seen what is going to stop this from being created in soft
upgrade.
I am adding a new class B2I_10_3 which will be used in case of soft upgrades.
I will add comments about disk format.
java/engine/org/apache/derby/modules.properties
o did you consider just altering the existing sort to take an additional
startup parameter rather than extending and creating a new module to sort?
just would be interested to know why one approach vs. the other.
The sorting will be required while creating the constraint only. For rest of
the
execution it acts like a non unique index. By adding a new module I felt I
won't
be touching the execution path of other functionality (like select) and they
will
retain the their performance.
But I can merge this code with exiting sorting routine if you feel that will be
better
way of handing it.
> provide support for unique constraint over 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: derby-3330-testcase.diff, derby-3330.diff,
> derby-3330v2.diff, derby-3330v3.diff, derby-3330v4.diff,
> FunctionalSpec_DERBY-3330-V2.html, FunctionalSpec_DERBY-3330.html
>
>
> Allow unique constraint over nullable field. Right now derby support unique
> constraint only over not null columns.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
