You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig Russell <cr...@oracle.com> on 2016/08/19 18:25:17 UTC
Change to JDO specification with regard to jdoql null handling
We have discussed changing the JDO specification in a small but significant way and I’d like to get feedback on it.
The current specification:
Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned false. Other subexpressions or [other values for variables might still qualify the candidate instance for inclusion in the result set.]
Proposed specification:
Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned null. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned null. Comparison of fields with null return null. Arithmetic expressions with null parameters return null. Optional.get() may return null. Optional.isPresent() is treated as !=null.
Boolean expressions with null operands:
true & null -> null
false & null -> false
true | null -> true
false | null -> null
This change aligns JDO with SQL NULL semantics and makes reasoning about JDOQL expressions more rational.
Craig L Russell
clr@apache.org
Re: Change to JDO specification with regard to jdoql null handling
Posted by Tilmann <za...@gmx.de>.
+1
But maybe we could add some clarifications:
"... Comparison of fields with null return null [except when compared to
'null']"
and for the operands:
!(null) = true (?)
Cheers,
Tilmann
On 08.09.2016 21:07, Michael Bouschen wrote:
> Hi,
>
> +1 changing the spec as proposed.
>
> Regards Michael
>
>> We have discussed changing the JDO specification in a small but significant way and I\u2019d like to get feedback on it.
>>
>> The current specification:
>> Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned false. Other subexpressions or [other values for variables might still qualify the candidate instance for inclusion in the result set.]
>>
>> Proposed specification:
>> Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned null. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned null. Comparison of fields with null return null. Arithmetic expressions with null parameters return null. Optional.get() may return null. Optional.isPresent() is treated as !=null.
>> Boolean expressions with null operands:
>> true & null -> null
>> false & null -> false
>> true | null -> true
>> false | null -> null
>>
>> This change aligns JDO with SQL NULL semantics and makes reasoning about JDOQL expressions more rational.
>>
>>
>> Craig L Russell
>> clr@apache.org
>>
>>
>>
>
Re: Change to JDO specification with regard to jdoql null handling
Posted by Michael Bouschen <mi...@akquinet.de>.
Hi,
+1 changing the spec as proposed.
Regards Michael
> We have discussed changing the JDO specification in a small but significant way and I\u2019d like to get feedback on it.
>
> The current specification:
> Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned false. Other subexpressions or [other values for variables might still qualify the candidate instance for inclusion in the result set.]
>
> Proposed specification:
> Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned null. Similarly, a failed cast operation, which would throw ClassCastException, is treated as if the subexpression returned null. Comparison of fields with null return null. Arithmetic expressions with null parameters return null. Optional.get() may return null. Optional.isPresent() is treated as !=null.
> Boolean expressions with null operands:
> true & null -> null
> false & null -> false
> true | null -> true
> false | null -> null
>
> This change aligns JDO with SQL NULL semantics and makes reasoning about JDOQL expressions more rational.
>
>
> Craig L Russell
> clr@apache.org
>
>
>
--
Michael Bouschen
akquinet tech@spree GmbH
B�lowstra�e 66 \u2022 D-10783 Berlin
Tel: +49 30 235520-33
Fax: +49 30 217520-12
E-Mail: michael.bouschen@akquinet.de <ma...@akquinet.de>
Web: www.akquinet.de <http://www.akquinet.de/>
Gesch�ftsf�hrung: Martin Weber, Dr. Torsten Fink
Amtsgericht Berlin HRB 86780 \u2022 USt.-Id. Nr.: DE 225 964 680
[Facebook] <http://www.facebook.com/akquinet> [XING]
<https://www.xing.com/companies/akquinetag> [G+]
<https://plus.google.com/b/111054946250796705170/+akquinet/posts>
[LinkedIn] <https://www.linkedin.com/company/akquinet-ag> [Twitter]
<https://twitter.com/akquinet>