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 Wed, 17 Oct 2007 14:09:54 GMT

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

Anurag Shekhar commented on DERBY-2212:

1) Current code changes B2I so needs upgrade code or else no old database with any index will
be able to be read.

I do have code for soft and hard upgrade in my todo list. I will create an jira for the same.

2) The approach seems complicated and error prone to me. Treating compare of nulls one way
through an extra overloaded arg sometimes and sometimes seems overly complicated.

It is just one of the possible approach I am trying it out only because I felt its a good
solution. I am open to take other approach.

3) I need to think about it more carefully to understand how treating compare of nulls differently
in the same tree might affect things like logical undo during restart recovery after an uncommitted
insert where the row may have moved drastically since the insert do to lots of other inserts.

I will write some tests related to this scenario and get back.

4) before commit needs a bunch of null heavy additional test cases.

Yes I need to write several test cases for new behaviour and also some make sure its not breaking
something else in some other part of the code base.

1) optimizer probably will assume 1 row from unique index in this case, now it may have to
use some other estimate when dealing with nulls. If the index was non-unique rather than unique
current code would just work. 

Optimizer has a provision to treat IS NULL differently from '='. I am using that in my current
patch and it appears to be working fine for very basic tests.

2) unique index locking isolation level algorithm is different from duplicate index locking
isolation level for serializable. It may have to now change. Previously a previous key lock
is not necessary to protect a "phantom" insert range for a unique index - after your change
maybe it is? Again if the index was marked non-unique at implementation level then current
code would just work. 

I need to check about it. I will test and debug the code in multi user mode and get back.

> 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:
>            Reporter: Oleksandr Alesinskyy
>            Assignee: Anurag Shekhar
>         Attachments: derby-2212preview.diff, derby-2212preview2.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.

View raw message