[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15152165#comment-15152165
]
Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:49 AM:
---------------------------------------------------------------
I still don't get the difference between empty and null. {{Optional}} does have
a {{ofNullable()}} method, which can be used to set it to {{null}}. Otherwise,
how do you set it to be `empty`?
I also think (as I mentioned earlier) properties of the underlying datastore
should ideally not affect the API too much (I guess that possibility
performance optimisations should be the main reason). After all we are writing
an OO API and staying true to the Java OO-Model makes it easier to use.
I can understand the worry about the implementation details. However, I work
with an object-database that represents the API data model (almost) 1:1. So
maybe you can understand that I would prefer not to have to deviate from the
1:1 OO representation only to make implementation in RDBMS easier.
As to whether {{List<List<...>>}} is valid, I think it is. We could disallow
{{Optional<Optional<..>>}} but that would mean deviating even further from the
Java object model.
@Renato:
I do like your proposal with viewing {{Optional}} as a collection. But I
suppose that would entail that the object referenced by the {{Optional}} can
only be accessed by {{get()}}, and that comparing {{Optional<Department>}} to a
{{Department}} in JDOQL would fail?
I will try to summarize a bit, basically it is `follow the way {{Optional}} is
implemented in Java` vs `follow the idea of {{Optional}}, as available in other
languages`:
1. We could strictly follow the Java object model and only access {{Optional}}
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user.
Also, the semantics would be clean (same a Java). Also: probably easier to
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows
the implementation of Optional). Also, there seem to be difficulties with
implementing this in an RDBMS.
2. We introduce auto-dereferencing and assume that a reference to an optional
cannot be null.
Advantages: less typing for users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may
make implementation in ODBMS harder. Also, there are still open questions:
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an {{empty}} keyword in
JDOQL for comparison with {{Optional}} fields.
c) What happens if a persistent class has an field {{Optional<...>}} that is
{{null}}? Answered by Craig: return {{false}} for match.
d) Should we could disallow {{== null}}? But how do we prevent comparison to a
parameter of type {{Optional}} that is {{null}} or another field of type
{{Optional}} that is {{null}}?
e) What about the {{Optional<Optional<..>>}} case, should they all be
auto-dereferenced? What if either of them is empty? Can we query for the first
being empty vs the second being empty? Answered by Craig: Can be disallowed.
f) By Renato: Return type of query: {{Optional<T>}} vs {{T}}
was (Author: tilmann):
I still don't get the difference between empty and null. {{Optional}} does have
a {{ofNullable()}} method, which can be used to set it to {{null}}. Otherwise,
how do you set it to be `empty`?
I also think (as I mentioned earlier) properties of the underlying datastore
should ideally not affect the API too much (I guess that possibility
performance optimisations should be the main reason). After all we are writing
an OO API and staying true to the Java OO-Model makes it easier to use.
I can understand the worry about the implementation details. However, I work
with an object-database that represents the API data model (almost) 1:1. So
maybe you can understand that I would prefer not to have to deviate from the
1:1 OO representation only to make implementation in RDBMS easier.
As to whether {{List<List<...>>}} is valid, I think it is. We could disallow
{{Optional<Optional<..>>}} but that would mean deviating even further from the
Java object model.
@Renato:
I do like your proposal with viewing {{Optional}} as a collection. But I
suppose that would entail that the object referenced by the {{Optional}} can
only be accessed by {{get()}}, and that comparing {{Optional<Department>}} to a
{{Department}} in JDOQL would fail?
I will try to summarize a bit, basically it is `follow the way {{Optional}} is
implemented in Java` vs `follow the idea of {{Optional}}, as available in other
languages`:
1. We could strictly follow the Java object model and only access {{Optional}}
via {{get()}} and so on.
Advantages: I think this would be least error prone and easiest for the user.
Also, the semantics would be clean (same a Java). Also: probably easier to
implement in an ODBMS.
Disadvantages: This goes against the spirit of {{Optional}} (However it follows
the implementation of Optional). Also, there seem to be difficulties with
implementing this in an RDBMS.
2. We introduce auto-dereferencing and assume that a reference to an optional
cannot be null.
Advantages: less typing for users. Also, may be easier to implement in RDBMS.
Disadvantage: Deviation from the OO-model may (slightly) confuse users and may
make implementation in ODBMS harder. Also, there are still open questions:
a) What to do with the meta-data info (see Renato's post)
b) How to compare with null/empty? We could introduce an {{empty}} keyword in
JDOQL for comparison with {{Optional}} fields.
c) What happens if a persistent class has an field {{Optional<...>}} that is
{{null}}?
d) Should we could disallow {{== null}}? But how do we prevent comparison to a
parameter of type {{Optional}} that is {{null}} or another field of type
{{Optional}} that is {{null}}?
e) What about the {{Optional<Optional<..>>}} case, should they all be
auto-dereferenced? What if either of them is empty? Can we query for the first
being empty vs the second being empty?
> 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)
