[jira] [Comment Edited] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146400#comment-15146400 ] Renato Garcia edited comment on JDO-751 at 2/14/16 6:42 AM: @[~tilmann] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. was (Author: rgarcia): [~apacheb...@tkuhn.de] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146397#comment-15146397
]
Renato Garcia commented on JDO-751:
---
What about the type of the returned field in the JDOQL result clause
{{person.address}}? Optional or T?
> 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146400#comment-15146400 ] Renato Garcia commented on JDO-751: --- [~apacheb...@tkuhn.de] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. > 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)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15146301#comment-15146301 ] Craig L Russell commented on JDO-751: - I'd suggest we consider a field of type Optional 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. 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 Optionalwhere department is null? Should JDOQL do double-auto-dereferencing? I would disallow Optional . @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)
