[ 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)