[
https://issues.apache.org/jira/browse/DERBY-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533912
]
Øystein Grøvlen commented on DERBY-2212:
----------------------------------------
Thanks for the patch, Anurag. Your approach to solving this seems OK to me. I
have a few questions and comments:
ControlRow: I do not quite understand all implications of your changes here,
and some comments explaining this would be good. Regarding the following code
that, if I have understood thing correctly, is executed if both key and index
row is equal for all columns and there are columns where both have null:
if (nullPart != -1) {
if (ascOrDesc[nullPart]) // true - Ascending order
return 1;
else
return -1;
}
1. I do not understand the reasoning behind the return values. I notice that
if I swap them, dropping a table does not fail anymore (I have not checked if
that breaks other operations).
2. What are the implications if there are several columns for which both have
null? You only test ascOrDesc for the latest column.
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.
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?
FromBaseTable: The comment above your code needs to be updated to reflect your
change.
SortController: Typos: 'defaul', 'other wise', 'returns if nulls are ...'
should be 'returns whether ...', 'true if they ...' should be 'true if null
values ...'
Nit: There is a lot of whitespace issues that I hope you will correct before a
final 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 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.
