[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=15755672#comment-15755672 ] Craig L Russell edited comment on JDO-751 at 12/16/16 10:27 PM: Patch looks good, including the new aggregate test. Trivial quibble: the indentation on public void testOptionalAggregation looks a bit strange. was (Author: clr): Patch looks good, including the new aggregate tes > 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 > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch-v10.txt, JDO-751-tck-patch-v11.txt, > JDO-751-tck-patch-v12.txt > > > 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] [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=15367840#comment-15367840 ] Craig L Russell edited comment on JDO-751 at 7/8/16 4:38 PM: - Starting to work on the specification: Persistent Object Model 6.4.3 java.lang.Optional JDO implementations must support fields of type Optional where T is an Immutable Object Class types, java.util.Date, Enum types, or Persistence-capable Class types. They may be mapped nullable datastore types or to Optional types at the option of the JDO implementation. When instantiating an instance from the datastore, the JDO implementation would get the value v from the datastore and assign the field f = Optional.ofNullable(v). When storing the field in the datastore, the persistence implementation would store the result of v = f.isPresent()?f.get():null. was (Author: clr): Starting to work on the specification: Persistent Object Model 6.4.3 java.lang.Optional JDO implementations must support fields of type Optional where T is any supported Object type. They may be mapped to nullable datastore types or to Optional types at the option of the JDO implementation. When instantiating an instance from the datastore, the JDO implementation would get the value v from the datastore and assign the field f = Optional.ofNullable(v). When storing the field in the datastore, the persistence implementation would store the result of v = f.isPresent()?f.get():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 > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch-v5.txt > > > 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] [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=15367840#comment-15367840 ] Craig L Russell edited comment on JDO-751 at 7/8/16 3:59 PM: - Starting to work on the specification: Persistent Object Model 6.4.3 java.lang.Optional JDO implementations must support fields of type Optional where T is any supported Object type. They may be mapped to nullable datastore types or to Optional types at the option of the JDO implementation. When instantiating an instance from the datastore, the JDO implementation would get the value v from the datastore and assign the field f = Optional.ofNullable(v). When storing the field in the datastore, the persistence implementation would store the result of v = f.isPresent()?f.get():null. was (Author: clr): Starting to work on the specification: Persistent Object Model 6.4.3 java.lang.Optional JDO implementations must support fields of type Optional where T is any supported Object type. They may be mapped to nullable datastore types or to Optional types at the option of the JDO implementation. > 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 > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch-v5.txt > > > 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] [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=15314463#comment-15314463
]
Tilmann Zäschke edited comment on JDO-751 at 6/4/16 12:38 PM:
--
While writing the unit test, I came up with the following test cases for
{{orElse}}:
{code:title=SupportedOptionalMethods.java|borderStyle=solid}
public void testOrElse() {
OptionalSample otherPC = new OptionalSample();
otherPC.setId(33);
String paramDecl = OptionalSample.class.getName() + " otherPcParam";
Object[] params = new Object[]{otherPC};
//equivalent to "(optionalPC != null ? optionalPC : otherPcParam) ==
null"
checkQuery("this.optionalPC.orElse(otherPcParam) == null", paramDecl,
params,
new Object[]{});
//equivalent to "(optionalPC != null ? optionalPC : otherPcParam) !=
otherPcParam"
checkQuery("this.optionalPC.orElse(otherPcParam) != otherPcParam",
paramDecl, params,
new Object[]{oidPC});
paramDecl = "Date myDateParam, Date otherDateParam";
checkQuery("this.optionalDate.orElse(otherDateParam) == myDateParam",
paramDecl,
new Object[]{DATE, DATE2},
new Object[]{oidPC});
paramDecl = "Date otherDateParam";
checkQuery("this.optionalString.orElse(otherDateParam) == otherDate",
paramDecl,
new Object[]{oidNull, oidEmpty, oidReferencedPC1});
checkQuery("this.optionalString.orElse(12345) == " + INTEGER,
new Object[]{oidPC});
checkQuery("this.optionalString.orElse(12345) == 12345",
new Object[]{oidNull, oidEmpty, oidReferencedPC1});
paramDecl = String.class.getName() + " myString";
checkQuery("this.optionalString.orElse(`xyz`) == otherString",
paramDecl,
new Object[]{STRING},
new Object[]{oidPC});
checkQuery("this.optionalString.orElse(`xyz`) == `xyz`",
new Object[]{oidNull, oidEmpty, oidReferencedPC1});
}
{code}
The main problem is that all of these tests seem somewhat artificial. Can
anyone suggest some real-world cases for using {{orElse}} in queries? Otherwise
it may make sense to drop support support for {{orElse}} for now, until we see
a need.
was (Author: tilmann):
While writing the unit test, I came up with the following test cases for
{{orElse}}:
{code:title=SupportedOptionalMethods.java|borderStyle=solid}
public void testOrElse() {
OptionalSample otherPC = new OptionalSample();
otherPC.setId(33);
String paramDecl = OptionalSample.class.getName() + " otherPCparam";
Object[] params = new Object[]{otherPC};
checkQuery("this.optionalPC.orElse(otherPCparam) == null", paramDecl,
params,
new Object[]{});
checkQuery("this.optionalPC.orElse(otherPCparam) != otherPCparam",
paramDecl, params,
new Object[]{oidPC});
paramDecl = "Date myDate, Date otherDate";
checkQuery("this.optionalDate.orElse(otherDate) == myDate", paramDecl,
new Object[]{DATE, DATE2},
new Object[]{oidPC});
paramDecl = "Date otherDate";
checkQuery("this.optionalString.orElse(otherDate) == otherDate",
paramDecl,
new Object[]{oidNull, oidEmpty, oidDummyPC});
checkQuery("this.optionalString.orElse(12345) == " + INTEGER,
new Object[]{oidPC});
checkQuery("this.optionalString.orElse(12345) == 12345",
new Object[]{oidNull, oidEmpty, oidDummyPC});
paramDecl = String.class.getName() + " myString";
checkQuery("this.optionalString.orElse(`xyz`) == otherString",
paramDecl,
new Object[]{STRING},
new Object[]{oidPC});
checkQuery("this.optionalString.orElse(`xyz`) == `xyz`",
new Object[]{oidNull, oidEmpty, oidDummyPC});
}
{code}
The main problem is that all of these tests seem somewhat artificial. Can
anyone suggest some real-world cases for using {{orElse}} in queries? Otherwise
it may make sense to drop support support for {{orElse}} for now, until we see
a need.
> 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
> Fix For: JDO 3.2
>
> Attachments: JDO-751-tck-patch-v2.txt
>
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2
[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=15307476#comment-15307476 ] Tilmann Zäschke edited comment on JDO-751 at 5/31/16 9:19 AM: -- Patch for the TCK with test classes and schema updates. I guess the next step is to update the reference implementation. was (Author: tilmann): Patch for the TCK with test classes dun schema updates > 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 > Fix For: JDO 3.2 > > Attachments: JDO-751-tck-patch.txt > > > 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] [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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:28 PM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to (age.isPresent() && paramOptInteger.isPresent && age.get()==paramOptInteger.get()) || !age.isPresent()) && !(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to (age.isPresent() && paramOptInteger.isPresent && age.get()==paramOptInteger.get()) || !age.isPresent()) && !(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification
[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=15153660#comment-15153660
]
Renato Garcia edited comment on JDO-751 at 2/19/16 11:38 AM:
-
{quote}
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`?
{quote}
You use Optional.empty(). Again, the idea of Optional is to abstract {{null}}
away. In the Optional world there are absolutely no nulls, and no {{null}}
references which would invalidate the whole concept as we talked before. Once
using Optional everything that is non-Optional is automatically assumed to be
non-nullable. You need to pick one approach and delimit this world well.
With this idea in mind, {{Optional.ofNullable()}} is for interoperability with
the non-Optional world because {{null}} is still out there. Also, note that you
are not "setting" {{null}}, because Optional is immutable, so you get back a
reference that represents empty. Equally you don't obtain {{null}} from an
Optional - you have to explicitly convert it back to {{null}}, which you'd only
do when you need to go back to non-Optional world. {{Optional.get}} will never
give you back a {{null}}, it raises an {{NoSuchElementException}}, therefore
the code below will always throw an exception:
{{Optional.ofNullable(null).get() == null}}
So you'd need to do something like:
{code}
Optional fooOpt = Optional.ofNullable(null);
boolean expr = (fooOpt.isPresent() ? fooOpt.get() : null) == null;
{code}
or
{{Optional.ofNullable(null).orElse(null) == null}}
was (Author: rgarcia):
{quote}
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`?
{quote}
You use Optional.empty(). Again, the idea of Optional is to abstract {{null}}
away. In the Optional world there are absolutely no nulls, and no {{null}}
references which would invalidate the whole concept as we talked before. Once
using Optional everything that is non-Optional is automatically assumed to be
non-nullable. You need to pick one approach and delimit this world well.
With this idea in mind, {{Optional.ofNullable()}} is for interoperability with
the non-Optional world because {{null}} is still out there. Also, note that you
are not "setting" {{null}}, because Optional is immutable, so you get back a
reference that represents empty. Equally you don't obtain {{null}} from an
Optional - you have to explicitly convert it back to {{null}}, which you'd only
do when you need to go back to non-Optional world. {{Optional.get}} will never
give you back a {{null}}, it raises an {{NoSuchElementException}}, therefore
the code below will always throw an exception:
{{Optional.ofNullable(null).get() == null}}
So you'd need to do something like:
{{
Optional fooOpt = Optional.ofNullable(null);
boolean expr = (fooOpt.isPresent() ? fooOpt.get() : null) == null;
}}
or
{{Optional.ofNullable(null).orElse(null) == 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)
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:28 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)|((!age.isPresent()))&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)||((!age.isPresent()))&&!(paramOptInteger.isPresent()) I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:33 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {{address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7)}} If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:34 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to {{ (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger is equivalent}} to {{ (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:38 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to (age.isPresent() && paramOptInteger.isPresent && age.get()==paramOptInteger.get()) || !age.isPresent()) && !(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to {{ (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger) || }} {{!age.isPresent()) && !(paramOptInteger.isPresent()) }} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:30 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent()))&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:36 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to {{ (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger) || }} {{!age.isPresent()) && !(paramOptInteger.isPresent()) }} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger}} is equivalent to {{ (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:31 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {{address!=null is equivalent to address.isPresent()}} address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {address!=null is equivalent to address.isPresent()} address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:31 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {address!=null is equivalent to address.isPresent()} address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:34 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger is equivalent}} to {{ (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) {{age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && }} {{ age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent())}} ^^^ I think the above makes the case for auto-boxing parameters and fields I did not
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:29 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent()))&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)|((!age.isPresent()))&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/19/16 4:32 AM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {{address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7)}} If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: {{address!=null is equivalent to address.isPresent()}} address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)| ( ( !age.isPresent())&&!(paramOptInteger.isPresent()) ^^^ I think the above makes the case for auto-boxing parameters and fields I did not see anything
[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=15152861#comment-15152861 ] Craig L Russell edited comment on JDO-751 at 2/18/16 8:56 PM: -- Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optionalis disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to !age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)||((!age.isPresent()))&&!(paramOptInteger.isPresent()) I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current specification that allows passing domain objects as parameters, so it's unnecessary to discuss passing Optional as parameters. Other comments from discussion above: I agree that there is a difference between null and empty, but it doesn't have to matter. When we persist an object where the address field is null, we store null in the datastore. If the address field is Optional.EMPTY, we store null in the datastore. When we retrieve the object from the datastore, the Optional will always be non-null. MemberMetadata.getFieldType should return "Optional". I don't see the problem with type erasure, since the metamodel uses strings to represent types. was (Author: clr): Here's another try at a solution. Optional is a Java domain modeling concept that is loosely followed in JDOQL to track the semantics but not necessarily the syntax. Optional is disallowed. If anyone can give a real example, I will listen. Mapping a persistent field of type Optional requires that the mapped database field be nullable. Add Optional as a JDOQL feature and allow methods get() and isPresent() to be used with JDOQL. Consider adding .equals to this but only if we can't figure out how to compare to null, other Optional, and primitive/boxed values. To make it easier to express in JDOQL, assume a simple domain model with a class Person with a field age of type Optional and field address of type Optional. Address contains String city, String state, String postalCode. The query is on class Person. The following are equivalent in JDOQL: address!=null is equivalent to address.isPresent() address.city=="New York" is equivalent to address.get().city=="New York" address.city=="New York" is equivalent to (address.isPresent() && address.get().city=="New York") address==null is equivalent to (!address.isPresent()) age==null is equivalent to age.isPresent() age==7 is equivalent to (age.isPresent() && age.get()==7) age==7 is equivalent to (age.get()==7) If using the result feature of JDOQL, specifying the result to be address, the type of the return value is Optional. Parameters can be passed as type Optional. setParameters("Optional paramOptInteger, Integer paramInteger, int paramInt") The following are equivalent in JDOQL: age==paramInt is equivalent to (age.isPresent() && age.get()==paramInt) age==paramInteger is equivalent to (age.isPresent() && age.get()==paramInteger) age==paramOptInteger is equivalent to (age.isPresent() && paramOptInt.isPresent && age.get()==paramOptInteger)||((!age.isPresent()))&&!(paramOptInteger.isPresent()) I think the above makes the case for auto-boxing parameters and fields I did not see anything in the current
[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=15152165#comment-15152165
]
Tilmann Zäschke edited comment on JDO-751 at 2/18/16 12:09 PM:
---
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>}} is valid, I think it is. We could disallow
{{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}} 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>}} 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}} vs {{T}}
Anything I missed? I think we more or less agreed on option 2) in the last
telecon, but I thought I list both options here because there still seem to be
some open issues.
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>}} is valid, I think it is. We could disallow
{{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}} 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
[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=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>}} is valid, I think it is. We could disallow
{{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}} 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>}} 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}} 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>}} is valid, I think it is. We could disallow
{{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}} 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
[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=15152197#comment-15152197
]
Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:45 AM:
---
@Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in
{{person.address.postcode}} is {{null}}.
So this would for example answer point e) (we disallow Optional>),
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and b)/d) about
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have
quite some impact I suppose...
was (Author: tilmann):
@Craig
Sorry, I think overlooked your post.
You raised an excellent point about JDOQL that return {{false}} if one in
{{person.address.postcode}} is {{null}}. But that means I can still compare to
So this would for example answer point e) (we disallow Optional>),
and c) (return {{false}}).
I think it leaves points a) metadata (Renato's point), and b)/d) about
comparison to {{null}}/{{empty}}. Disallowing comparison to {{null}} could have
quite some impact I suppose...
> 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] [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=15152165#comment-15152165
]
Tilmann Zäschke edited comment on JDO-751 at 2/18/16 11:19 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>}} is valid, I think it is. We could disallow
{{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}} 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>}} 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?
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>}} is valid, I think it is. We could disallow
{{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}} 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
[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] [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=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 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 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)
[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=15144615#comment-15144615 ] Tilmann Zäschke edited comment on JDO-751 at 2/12/16 2:20 PM: -- ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But, at least ideally, I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? was (Author: tilmann): ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? > 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] [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=15144615#comment-15144615 ] Tilmann Zäschke edited comment on JDO-751 at 2/12/16 2:15 PM: -- ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields??? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance??? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? was (Author: tilmann): ??How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields? ?? I think it is related because auto-dereferencing means that you assume that the reference to the Optional cannot be null. ??I don't think Optional can reference null, it's either a value or "empty".?? So how would one check for "empty"? Would the only possibility be via "isPresent()"? ??In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance? ?? I don't know. But I'm not sure that the difficulty of implementing a feature in an RDBMS should guide the design of an API for object oriented persistence? > 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] [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=15145027#comment-15145027
]
Tilmann Zäschke edited comment on JDO-751 at 2/12/16 6:38 PM:
--
Maybe it should also be considered whether JDO may at some point want to add
something like lambdas / streams do JDOQL. In that case, it would be useful to
have the {{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.
was (Author: tilmann):
Maybe it should also be considered whether JDO may at some point want to add
something like lambdas do JDOQL. In that case, it would be useful to have the
{{isPresent()}}, {{orElse(...)}} and {{get()}} methods available.
> 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] [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=15142722#comment-15142722
]
Tilmann Zäschke edited comment on JDO-751 at 2/11/16 1:31 PM:
--
??perhaps it should be also true that querying with null on an Optional has
undefined behaviour; which is not a big deal because in practice since you
shouldn't be doing it anyway and when you are using Optional this distinction
becomes irrelevant.??
I think that one of the design goals of JDOQL was to be close to Java. I think
it's already a bit problematic to introduce shortcuts that have different
semantics than Java, but I really don't think it's a good idea to intentionally
prevent simple operations (comparison of Optional to null) in JDOQL that are
possible in Java and give them different meaning in JDOQL.
On a separate note, I saw that {{Optional}} is not {{Serializable}}, and it
seems to be only intended (or useful) for lambdas/streams. I even saw someone
mentioning that they considered calling it {{OptionalReturn}} to indicate that
it should only be used as return value.
There is one thing that I would find interesting though: The semantic of
{{Optional}} means that it cannot be modified, i.e. it is an immutable
reference. Translated to a DBMS, that would mean that {{Optional}} protects a
reference such that the referenced object cannot be deleted.
In summary, I think {{Optional}} is not intended by the Java designers to be
serializable, so maybe JDO should not support this either. However, if we do
support it, I'm still somewhat opposed to shortcuts, because they change the
semantics. However I would support the non-deletability of referenced objects,
because that would be an interesting feature and would better reflect the
semantics of {{Optional}}.
was (Author: tilmann):
??perhaps it should be also true that querying with null on an Optional has
undefined behaviour; which is not a big deal because in practice since you
shouldn't be doing it anyway and when you are using Optional this distinction
becomes irrelevant.??
I think that one of the design goals of JDOQL was to be close to Java. I think
it's already a bit problematic to introduce shortcuts that have different
semantics than Java, but I really don't think it's a good idea to intentionally
prevent simple operations (comparison of Optional to null) in JDOQL that are
possible in Java and give them different semantics.
On a separate note, I saw that {{Optional}} is not {{Serializable}}, and it
seems to be only intended (or useful) for lambdas/streams. I even saw someone
mentioning that they considered calling it {{OptionalReturn}} to indicate that
it should only be used as return value.
There is one thing that I would find interesting though: The semantic of
{{Optional}} means that it cannot be modified, i.e. it is an immutable
reference. Translated to a DBMS, that would mean that {{Optional}} protects a
reference such that the referenced object cannot be deleted.
In summary, I think {{Optional}} is not intended by the Java designers to be
serializable, so maybe JDO should not support this either. However, if we do
support it, I'm still somewhat opposed to shortcuts, because they change the
semantics. However I would support the non-deletability of referenced objects,
because that would be an interesting feature and would better reflect the
semantics of {{Optional}}.
> 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] [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=15140104#comment-15140104
]
Renato Garcia edited comment on JDO-751 at 2/10/16 8:25 PM:
{quote}
Just to clarify the first question: I see that 'Optional' should be allowed to
reference persistence classes (as FCOs) as well as SCOs (such as String, ...).
But I guess Optional itself should not be a persistent type?
{quote}
Optional type can be seen as a collection containing zero or one item, so
perhaps it would make sense to address them the same way the spec addresses the
other collection types.
Regarding JDOQL support, I kind of like the idea of supporting methods like
isPresent and make a distinction as Tilmann has mentioned above.
Also, given the following scenario: Person FCO with an Optional
I think it would probably be nice to be able to just write something like this
in the query filter:
{code:java}
person.address.postCode == foo
{code}
instead of having to deference the value using get
was (Author: rgarcia):
{quote}
Just to clarify the first question: I see that 'Optional' should be allowed to
reference persistence classes (as FCOs) as well as SCOs (such as String, ...).
But I guess Optional itself should not be a persistent type?
{quote}
Optional type can be seen as a collection containing zero or one item, so
perhaps it would make sense to address them the same way the spec addresses the
other collection types.
Regarding JDOQL support, I kind of like the idea of supporting methods like
isPresent and make a distinction as Tilmann has mentioned above.
Also, given the following scenario: Person FCO with an Optional
I think it would probably be nice to be able to just write something like this
in the query:
{code:java}
person.address.postCode = foo
{code}
instead of having to deference the value using get
> 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] [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=15138522#comment-15138522 ] Andy Jefferson edited comment on JDO-751 at 2/9/16 8:25 AM: >From Apache JDO "minutes" Q. Does it make sense to support Optional as a persistent type? It would need to map to a nullable datastore value. So Optional can be the type of a persistent field iff T can be the type of a persistent field. Does it make sense to support Optional as a first class object? If an Employee has a field Optional can the field be treated as first class? Q. Could Employee.getDepartment() return an Optional? Answer : yes to both. A user can have fields of types like Optional, Optional and would expect these to be mapped in the datastore to a column that accepts NULLs, and of the equivalent type of T. Similarly they could have a 1-1 relation via a field of type Optional (i.e creating the FK to the table of MyOtherType). The other aspect of this would be in terms of JDOQL and queryability of such fields. Following the idea that JDOQL attempts to have Java syntax then we should have methods optionalField.isPresent() returning a BooleanExpression optionalField.get() returning an expression of the type of the T type, so StringExpression, DateExpression, etc. The alternative to this is just to let the user do "== NULL" to check if a value is present. Comments? was (Author: andy): >From Apache JDO "minutes" Q. Does it make sense to support Optional as a persistent type? It would need to map to a nullable datastore value. So Optional can be the type of a persistent field iff T can be the type of a persistent field. Does it make sense to support Optional as a first class object? If an Employee has a field Optional can the field be treated as first class? Q. Could Employee.getDepartment() return an Optional? Answer : yes to both. A user can have fields of types like Optional, Optional and would expect these to be mapped in the datastore to a column that accepts NULLs, and of the equivalent type of T. Similarly they could have a 1-1 relation via a field of type Optional. The other aspect of this would be in terms of JDOQL and queryability of such fields. Following the idea that JDOQL attempts to have Java syntax then we should have methods optionalField.isPresent() returning a BooleanExpression optionalField.get() returning an expression of the type of the T type, so StringExpression, DateExpression, etc. The alternative to this is just to let the user do "== NULL" to check if a value is present. Comments? > 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)
