[
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536039
]
Øystein Grøvlen commented on DERBY-2212:
----------------------------------------
To my previous comment: I was rather confused when I asked whether we need to
have indexes that treat null as equal. As far as I can tell, we want look-ups
(and deletes) to treat nulls as equal (in order to find rows where a specific
column is null), but we want nulls to be treated as not equal on insert. (I
think the reason for my confusion was that I mixed this with whether we need
some indexes that treat null as equal on insert and other indexes that treat
null as not equal on insert. I think we only need the latter. Please, correct
me if I am wrong.)
So Anurag's approach is to add a parameter to compare methods so that on
navigation on insert, compare is told to treat null as not equal while on
look-ups compare is told to treat null as equal. The question is whether there
is a clean way to separate the two navigational modes. With the current patch,
it is not that straight-forward to detect whether there are situations where
nulls are treated as equal on insert or where nulls are treated as not equal on
look-ups. Is there a way to make that more clear and less error-prone?
> 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.