db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dibyendu Majumdar <dibye...@mazumdar.demon.co.uk>
Subject Re: [jira] Commented: (DERBY-3330) provide support for unique constraint over nullable columns
Date Thu, 28 Feb 2008 02:15:56 GMT
Hi Mike,

I did go through DERBY-2212 - but did not think it had the same  
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 ...



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:
>>>         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.

View raw message