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-2212) Add "Unique where not null" to create index
Date Sat, 03 Nov 2007 05:43:05 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539841
] 

Anurag Shekhar commented on DERBY-2212:
---------------------------------------

thanks Øystein, for the review and trying out the patch.

 

 
1. I do not understand the reasoning behind the return values.  I notice that if I swap them,
dropping a table does not fail anymore (I have not checked if that breaks other operations).

In this case return value (1) is not important. But the sign is important because that determines
the sequence of sorted keys (used while creating index on a table with existing records. While
creating the B Tree first time the keys are supposed to be in a sequence and this is  verified
by invoking method in ControlRow. So if there are duplicate nulls are present in table they
should still confirm the sequence (depending on the flag passed ascOrDesc []).
Yes I saw the drop works fine if I change the sequence but in that case creating of index
on table with existing records will fail.

I have found the problem which is causing the drop table to fail. Its happening while scanning
catalog's table to remove table index. Some of the attribute in index record are null and
while comparing these two nulls are treated unequal and the deleting fails. I making changes
to fix this and will be posting them after incorporating your other comments. 

 
2 .What are the implications if there are several columns for which both have null?  You only
test ascOrDesc for the latest column.

I am changing this part of code. Now the first null will ensure a mismatch and ascOrDesc flag
for that column will be used. But I think it shouldn't matter for which null ascOrDesc is
used as this is used only by Sorter and it doesn't makes any difference in which order these
two  record are sorted (at least till we have something like row id). 


I will get back back about other questions.
 




> Add "Unique where not null" to create index
> -------------------------------------------
>
>                 Key: DERBY-2212
>                 URL: https://issues.apache.org/jira/browse/DERBY-2212
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.2.1.6
>            Reporter: Oleksandr Alesinskyy
>            Assignee: Anurag Shekhar
>         Attachments: derby-2212preview.diff, derby-2212preview2.diff, FunctionalSpec.html,
FunctionlaSpecv2.html
>
>
> Derby prohibits creation of unique constraints on nullable colums (as well if only some
columns in the constraint list are nullable) and treat nulls in unique indexes as normal values
(i.e. only one row with null values in indexed columns may be inserted into the table). This
bahavior is very restrictive, does not completely comply with SQL standards (both letter and
intent) as well as with business needs and intending meaning of NULL values (2 null values
are not considered as equal, this comparision shall return NULL, and for selection criteria
boolean null is treated as FALSE).
> This behavior, as far as I can see, is modelled after DB2 (and differs from behavior
of most other major databases, like SyBase, Oracle, etc.).
> But even DB2 provide some means to alleviate these restrictions, namely "UNIQUE WHERE
NOT NULL" clause for CREATE INDEX statement.
> It will be very good if such "UNIQUE WHERE NOT NULL" clause will be introduced in Derby.
> Regards,
> Oleksandr Alesinskyy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message