-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: V4.0_WD01
-
Fix Version/s: V4.0_WD01
-
Component/s: URL Conventions
-
Labels:None
-
Environment:
[Applied]
-
Proposal:
-
Resolution:
I didn't see any mention of lifted operators in the working drafts. We should define how each operator behaves when one (or both) operands is null.
With that said, the V3 spec (section 2.2.3.6.1.1.5) is inconsistent with it's treatment of null:
- For equality operators, null eq null is true and null eq <anything not null> is false (i.e. the result is true or false)
- Any relational operators when compared with null are false (i.e. the result is true or false)
- This implies that null ge null and null le null is false which is inconsistent with null eq null is true
- Logical operators treat null as false (i.e. the result is true or false)
- Unary operators are null if the operand is null (i.e. in the case of not, the result is true, false, or null)
I've tried over the past 2 weeks to come to terms with the proposal, but I still have a fundamental problem accepting the idea of null = null.
I think it's easiest, and "least astonishing" to the user to say that:
<null value> eq null is true (I can test for null)
<null value> eq <null value> is false (two nulls values are defined to be not equal)
and that the null literal cannot be used with any other comparison operators (it doesn't make sense to compare something as less than or greater than null).
Matthew and Mike will prepare a proposal for the January F2F in Zürich
Accepted in F2F 2013-06-13
Accepted on 2013-06-20
I 100% agree with that; 3-value logic definitely complicates things. And if one of the goals of OData is to keep things simple, 3-value logic is probably not the correct approach to take.
I am definitely fine with using 2-value logic as long as we make the results consistent. In which case I still think proposal 1) from the post on "16/Dec/12 04:47 PM" has the most consistent treatment of nulls and simplest to understand.