[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144286#comment-15144286
]
Renato Garcia edited comment on JDO-751 at 2/12/16 9:10 AM:
------------------------------------------------------------
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?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional<T> and the JDOQL reflects the Java model
and not the datastore model?
In general Optional like classes (scala.Option, guava's Optional) are an
alternative approach to represent nullability, where you don't use {{null}} in
your code, so ideally this should be extended to the query and not force people
to use {{null}} for querying. They are not interchangeable and you shouldn't
mix them - You either use one or the other. Therefore, querying with {{null}}
when using Optional is conceptually wrong, and I guess making this the
recommended/official way just seems odd... What about datastores that can store
Optional and keep it's empty/null distinction? I believe that how it is mapped
to the datastore should be an implementation detail.
If there will be no support for methods (although I think that methods would
make the query more expressive), then just using variables would suffice by
passing an {{Option.empty()}} as parameter to query for "empty" and
{{Optional.of(value)}} for value, so no special cases.
was (Author: rgarcia):
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?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional<T> and the JDOQL reflects the Java model
and not the datastore model?
In general Optional like classes (scala.Option, guava's Optional) are an
alternative approach to represent nullability, where you don't use {{null}} in
your code, so ideally this should be extended to the query and not force people
to use {{null}} for querying. They are not interchangeable and you shouldn't
mix them - You either use one or the other. Therefore, querying with {{null}}
when using Optional is conceptually wrong, and I guess making this the
recommended/official way just seems odd... What about datastores that can store
Optional and keep it's empty/null distinction? I believe that how it is mapped
to the datastore should be an implementation detail.
If there will be no support for methods (although I think that methods would
make the query more expressive), then just using variables would suffice by
passing an {{Option.empty()}} as parameter to query for "empty" and {{
Optional.of(value) }} for value, so no special cases.
> 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)
