db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2212) Add "Unique where not null" to create index
Date Fri, 19 Oct 2007 16:08:51 GMT

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

Mike Matrigali updated DERBY-2212:

Derby currently does not support creating a unique constraint on a column with nullable keys,
and sql defines what the behavior should be in this case which I believe is the intent of

this work.  So in the case of constraints I don't think additional syntax is necessary, internally
we would use this new implementation to allow a unique constraint that supported duplicate

If we decide to also to allow one to create indexes through the create index command that

match this behavior then I agree additional syntax should be used.

I also agree that this implementation would lead to a "third" kind of index and that should
be somehow reflected in the system catalog description of the index.  Using this the optimizer
should be able to make correct assumptions about non-null uniqueness.  Some work will 
have to be done to code that tries to use existing indexes if a user asks for the same kind
of index to be created to understand the difference between this index and others.

I didn't put much thought to the create index behavior.  The storage system does provide a
way to optimize building indexes, it allows the tree to one loaded at create time by providing
a sorted stream of rows.  The btree itself does not own how the stream is produced.  It already
does a sanity check on each adjacent row to insure the sort of the keys, so it would be simple
to add a different check in the case of this new btree type.  See 

 a Derby does sometimes optimize this by throwing all rows through the sorter and then builds
the tree from the bottom up.  As was suggested this method could still be used at the cost
of adding a single compare of 
each row to it's previous if it has no null in it.  The system already does a compare at this

stage to insure

> 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