[
https://issues.apache.org/jira/browse/DERBY-3456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573017#action_12573017
]
A B commented on DERBY-3456:
----------------------------
When creating the backing index for a constraint, Derby currently attempts to
share conglomerates if there is an existing conglomerate such that:
1. the set of columns and their order in the constraint-backing index is the
same
as that of an existing index AND
2. the ordering attributes are the same AND
3. both the already-existing index and the constraint-backing index being
created
are non-unique OR the already existing index is unique
If all three of these conditions are true then Derby will use a single physical
conglomerate to support the already-existing index and the new
constraint-backing index.
So my question is: when unique constraints over nullable columns are
introduced, will this criteria (found in CreateIndexConstantAction.java; search
for "shareExisting") need to be updated? In particular, I'm wondering if #3 is
still good enough, or will additional logic for nullable unique constraints
need to be added?
> 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: derby-3456v1.diff, upgradetests.diff
>
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
