[
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534035
]
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 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.
