Hi Mike,
I did go through DERBY-2212 - but did not think it had the same
proposal.
However, you may be referring to the concerns you have with using
unique index to store duplicate values.
Does the recovery code use a different comparison routine compared to
the normal case?
I don't want to open up an older debate unnecessarily - so apologies
if what I have proposed has been considered and discarded. Just that
the current solution seems pretty complex ...
Regards
Dibyendu
On 28 Feb 2008, at 00:59, Mike Matrigali wrote:
see discussion in DERBY-2212 for various issues related to this
project that led to the current design.
Dibyendu Majumdar (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3330?
page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
tabpanel&focusedCommentId=12573108#action_12573108 ] Dibyendu
Majumdar commented on DERBY-3330:
------------------------------------------
Hi,
I could be talking nonsense here so please tell me to shut up if I
have got the wrong end of the issue. If I understand correctly,
one of the requirements is to allow multiple rows to be inserted
where the index is unique and all columns are null. This doesn't
work currently because such rows will be considered duplicates.
Thinking very naively, I would implement this as follows:
I am assuming that when index rows are stored, Derby always stores
an additional column containing the row location, regardless of
the type of index.
Also that the search algorithm is uniform for both unique and non-
unique indexes, with the only difference being that the unique
index searches do not consider the extra row location column.
Following is invalid if above assumptions are not true.
To get the desired behaviour, I would simply change the comparison
logic as follows:
a) If non-unique index, no change.
b) If unique index, and all indexable columns are null, then
compare the extra (last) (row location) column.
c) The else case for unique index will remain the same as now.
If the key comparison routine always used above logic, would it
not give desired behaviour without requiring any significant
changes to the existing implementation?
As I said, I may totally off track here, so please feel free to
tell me to shut up.
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: BTreeController.diff, derby-3330-
testcase.diff, derby-3330.diff, derby-3330v10.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, FunctionalSpec_DERBY-3330-
V2.html, FunctionalSpec_DERBY-3330.html,
UniqueConstraint_Implementation.html,
UniqueConstraint_Implementation_V2.html,
UniqueConstraint_Implementation_V3.html
Allow unique constraint over nullable field. Right now derby
support unique constraint only over not null columns.
