[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146301#comment-15146301
]
Craig L Russell commented on JDO-751:
-------------------------------------
I'd suggest we consider a field of type Optional<T> to be of type T in the
JDOQL and persistence domains. This is quite similar to some automatic behavior
in Java where a field of type Integer is auto-(un)boxed where an int is
required. Even though the semantics of non-null database fields are identical
to int, and null database fields are identical to Integer, we allow mapping
either way. In JDOQL we don't require explicit checking for null-valued fields.
Dereferencing a null-valued database field results in disqualifying the JDOQL
clause, not throwing an exception.
The example in JDOQL person.address.postCode == foo is instructive. The
persistent field address is declared as Optional<Address>. For the purposes of
this discussion, it doesn't matter whether Address is mapped as first class or
second class.
If we use strict Java semantics in JDOQL, we have (person.address.isPresent()
&& person.address.get().postCode == "2BRN2B"). Very similar to what we rejected
in JDOQL to handle nulls: (person.address!=null && person.address.postCode ==
"2BRN2B").
Usability is the reason we rejected this and opted for the simpler
person.address.postCode == "2BRN2B".
Do we plan to add streams/lambdas to JDOQL? How about executing user-defined
(domain) methods in the datastore? I think that there will be many more issues
than Optional if/when we get to these features.
@Tilmann: How do we treat Optional<Optional<Department>> where department is
null? Should JDOQL do double-auto-dereferencing?
I would disallow Optional<Optional<Department>>.
@Renato: What would be the type of the parameter for a variable in a query?
From what I understand it would be T to be consistent with accepting null?
Yes, the parameter would be of type T for parameters. The parameter could be
null or non-null.
> Support for Java8 Optional
> --------------------------
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
> Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
