Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <14593125.1192531550898.JavaMail.jira@brutus>
Date: Tue, 16 Oct 2007 03:45:50 -0700 (PDT)
From: "Anurag Shekhar (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-2212) Add "Unique where not null" to
 create index
In-Reply-To: <20254731.1167917367874.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Anurag Shekhar commented on DERBY-2212:
---------------------------------------

>3. This code will not be executed for partial key matching. Hence, null values will always be treated equal in that case. Is that intentional? If yes, it would be good if that would be clear from the specification of the method, and not just be an implicit assumption based on how partial key matching is currently used.

Partial key matching is used only for searching. While searching (either for update or select) null should be treated equal. So this code shouldn't get executed. 

DataType#compare: Are you sure that nullsOrderedLow does not matter when both values are null? I am a bit confused,so it would be good if you could add a convincing comment. And why return -1 and not 1 if nulls are not equal? Does this work equally well for both ascending and descending scans?

nullsOrderedLow is used for ordering nulls with respect to not null values (in order by clause with null ordering option) so when two nulls are being compared this flag is not relevant.

-1 or 1 result of the null comparison will only effect where new node will be inserted (left or right of the existing node). The spec in my opinion doesn't mandates it. So I think its ok to return either -1 or 1. Please let me know if I am wrong.

 
> 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.