[
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-2212:
----------------------------------
i am not sure any of the following are problems, but things to think about.
These all stem from now you have a unique index that may return multiple rows
for a given value if that value is null
(or in the more interesting case if one of the columns of a multiple key column
is null). The current derby system may assume this is not possible and may
affect the following areas:
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.
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.
3) some language and store positioning code may assume that an exact key on a
unique index will only resolve to one row - now it may not. i don't know where
all this code is just warning that it is something to look for. Again if code
was marked non-unique vs unique
then code continues to work.
I still think at the store level putting multiple null's in makes the index
non-unique and the code is cleaner if we just treat it that way - rather than
special casing the compares like
your patch.
> 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
>
>
> 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.
