[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155124#comment-15155124
]
Renato Garcia commented on JDO-751:
---
{quote}
MemberMetadata.getFieldType should return "Optional". I don't see the
problem with type erasure, since the metamodel uses strings to represent types.
{quote}
It would certainly work, but this would be inconsistent with containers i.e.
collections/maps/arrays, which are also parameterized types just like
Optional, thus creating a special case just to support Optional. In my
opinion this would be not justifiable when you could just use the existing
approach for containers.
> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15155121#comment-15155121
]
Renato Garcia commented on JDO-751:
---
{quote}
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.
{quote}
I totally agree, and I'm not ignoring the other datastores - In fact I'm
proposing something in the middle, which should work well with any datastore
and with the only trade-off of deviating from Java semantics in a scenario that
has no usage in practice. If you go in the other direction, you would be biased
towards datastores that can represent this seamless. Anyway, if the spec
mandates that the semantics are kept for Optional reference null checks, in
practice you would be forcing datastores that use {{null}} to also cater for
'empty' for the pure sake of useless semantics, resulting in an unnecessary
inefficiency; and most likely implementations will have a sane option where you
can choose to be non-spec compliant and not have this semantics and be more
aligned to the datastore model - which of course is what people will be using.
So why make it more complicated a make people implementing the API (myself
included here :)) waste their time supporting something that has no practical
use, when the spec could anticipate this and be more aligned to reality? Note
that you could still implement the semantics in any datastore if you choose to,
and if anyone cares about it, they just choose to use a implementation where
this is supported or contributing to the implementation with this support.
{quote}
@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?
{quote}
Not necessarily, as I think this should still work with the "auto-conversion"
that Craig is proposing; but ideally yes, it should fail.
> 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&focusedCommentId=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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15153660#comment-15153660
]
Renato Garcia commented on JDO-751:
---
{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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146467#comment-15146467
]
Renato Garcia commented on JDO-751:
---
Treating it just as T on the APIs/query would require you to convert your
Optional to nullable references again in order to pass it as a parameter in a
query, and something that you want to avoid. Ideally when using Optional idiom
you don't convert it back and forwards to null, you just use your Optional ref.
I believe that proper support of Optional idiom in JDO would mean not forcing
people to write null and converting Optional values back and forward to
nullable refs.
I reckon that exposing Optional as the type on the API/Query makes the
solution more consistent, regular and requires less special cases, except for
the auto de-referencing of course, which is part of the proposed solution
anyway.
In my view, there are similarities in boxing of primitives and the Optional,
however there is a key difference: When using boxing they represent the same
value, whereas "null" and "empty" are just not the same thing - you are not
wrapping null (this would equivalent to {{Optional.of(null)}} which throws an
NPE). My opinion is that this is a fundamental difference and therefore
important to keep the semantics in this scenario. On the other hand, when
querying using "null" on a Optional field, the result would be less relevant
because, again, it makes no sense when using Optional to do so (even though it
is possible in Java, guess what? Also doesn't make sense since they shouldn't
be null and being null is an error(NPE), hence no use in practice). So I think
it is reasonable that in practice for this scenario, it could either be invalid
or dependent on the underlying implementation/datastore; but again, the only
single and simple reason you'd use Optional is to replace the usage of null.
Nevertheless, if one day someone manage to use null and Optional together (kind
of a paradox?!?!), in a super clever way, I'm sure they will have a solution
that overcomes this limitation as well! :)
Regarding viewing Optional as T, there are some implications such as how to
handle metadata. For instance, what {{MemberMetadata.getFieldType}} should
report? T or Optional - in either case how do you represent that with type
erasure in mind and JDO metadata model keeping both types, preferably without
causing too much impact and discrepancy with existing approach.
A possible alternative would be to view Optional as a container of , or
simply a collection, which happens to have zero or one element only. From my
experience, in my attempts to implement an experimental support for Optional
types in DN, I found the container approach more aligned and easier to abstract
in terms of current JDO concepts/metadata; requiring less forgery - possibly
because it is closer to what it actually is being represented. Of course this
conclusion is also highly influenced by the DN implementation, but I think it
is still valid observation. It's worth noting that I think they are both valid
views after having explored both paths.
> 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&focusedCommentId=15146400#comment-15146400 ] Renato Garcia edited comment on JDO-751 at 2/14/16 6:42 AM: @[~tilmann] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. was (Author: rgarcia): [~apacheb...@tkuhn.de] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146400#comment-15146400 ] Renato Garcia commented on JDO-751: --- [~apacheb...@tkuhn.de] I've edited to my comment to clarify what I meant about using "null" as a parameter and expect "empty" results. > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [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&focusedCommentId=15144286#comment-15144286
]
Renato Garcia edited comment on JDO-751 at 2/14/16 6:35 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. "Empty" and "null" are not the same
thing, and therefore, querying for "empty" using {{null}} on a 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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146397#comment-15146397
]
Renato Garcia commented on JDO-751:
---
What about the type of the returned field in the JDOQL result clause
{{person.address}}? Optional or T?
> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145294#comment-15145294
]
Renato Garcia commented on JDO-751:
---
{quote}I think it is related because auto-dereferencing means that you assume
that the reference to the Optional cannot be null.{quote}
Not necessarily, it depends on how you do it. It would be probably something
{{orElse(null)}} rather then {{get()}} to be compatible with JDOQL handling of
nulls.
{quote}So how would one check for "empty"? Would the only possibility be via
"isPresent()"?{quote}
In a query? Either comparing to "empty" using a variable or calling "isPresent"
if the method is implemented.
{quote}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?{quote}
Exercising the possible implementations is a good guidance of the practicality
of the API and helps understand the trade-offs imposed by the API.
> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15145293#comment-15145293
]
Renato Garcia commented on JDO-751:
---
{quote}Fun question (not a likely use-case): How do we treat
Optional> where department is null? Should JDOQL do
double-auto-dereferencing?{quote}
Would it be a valid mapping to start with? Is {{List>}} valid?
> Support for Java8 Optional
> --
>
> Key: JDO-751
> URL: https://issues.apache.org/jira/browse/JDO-751
> Project: JDO
> Issue Type: New Feature
> Components: specification, tck
>Reporter: Andy Jefferson
>
> java.util.Optional provides a feature that is available in other languages.
> Since JDO 3.2 will be for Java8+ then it makes sense to add support for this
> as a "supported persistable type"
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144519#comment-15144519 ] Renato Garcia commented on JDO-751: --- I don't think Optional can reference null, it's either a value or "empty". > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144516#comment-15144516 ] Renato Garcia commented on JDO-751: --- In case we would like to make it not ambiguous in JDOQL how would this be implemented in a RDBMS for instance? How is this related to the "shortcuts" changing semantics, as in "shorcuts" meaning auto dereference of Optional fields? > Support for Java8 Optional > -- > > Key: JDO-751 > URL: https://issues.apache.org/jira/browse/JDO-751 > Project: JDO > Issue Type: New Feature > Components: specification, tck >Reporter: Andy Jefferson > > java.util.Optional provides a feature that is available in other languages. > Since JDO 3.2 will be for Java8+ then it makes sense to add support for this > as a "supported persistable type" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144507#comment-15144507 ] Renato Garcia commented on JDO-751: --- You shouldn't have null references when using Optional, it defeats the purpose of the whole thing, otherwise you would need to check the reference to the Optional and then check the value of the 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] [Commented] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144287#comment-15144287 ] Renato Garcia commented on JDO-751: --- Regarding "shortcuts", I don't see why they change semantics? Aren't they just syntax sugar? I do think that more thought should be put into it though. > 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&focusedCommentId=15144286#comment-15144286
]
Renato Garcia edited comment on JDO-751 at 2/12/16 9:10 AM:
What would be the type of the parameter for a variable in a query? From what I
understand it would be T to be consistent with accepting null?
Wouldn't it still be dereferencing Optional instead of nulls, given that the
actual type of the field is Optional 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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15144286#comment-15144286
]
Renato Garcia commented on JDO-751:
---
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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142108#comment-15142108
]
Renato Garcia commented on JDO-751:
---
{quote}
But what happens in your example if foo is a variable and is null?
{quote}
It would just filter the {{Address}} instances that have postCode {{null}}, in
a scenario that postCode is a *non*-{{Optional}}.
On the other hand if {{address}} is {{empty}}, it would have same behaviour of
nullable fields on navigation.
{quote}
Could foo also be an Optional instance?
{quote}
Yes, as long as {{postCode}} is of type {{Optional}} that would fine. The
type matching should be just like the any other and in this case it should
accept {{null}}, since Java does as well, and {{Optional}}, but not {{T}}.
Even though the Java compiler doesn't prevent you from assigning {{null}} to an
{{Optional}} reference it is considered bad practice or semantically wrong (it
can/should be handled by static analysis tools). So I think the same idea
should apply to the query. Therefore, while I think that {{"date == null"}}
shouldn't be the same as {{!date.isPresent()}}, considering that it can be
cumbersome to implement the difference between {{null}} and {{empty}} in some
datastores(unless you store the empty state), like RDBMS for instance, 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.
{quote}
I think the shortcut looks nice, but I'm not convinced it can be implemented
without inconsistencies.
{quote}
I think the {{Optional}} deference/shortcuts are similar to what is done with
getters. Instead of writing(assuming no Optional involved):
{{person.getAddress().getPostCode() == foo}} you can write
{{person.address.postCode == foo}}, which is not consistent with the respective
Java code too, but very convenient.
The deference would only be for navigation on the filter, but on results would
still return an Optional of course. I don't see this as inconsistent but it's
definitely a special case. In my opinion it pays off to have a special
treatment (unless we come up with something better than deferencing it with
get) given that when you decide to use Optional instead of null to represent
nullability/optionality, it becomes very common pattern on your model, so
providing a special syntax makes a lot of sense.
{quote}
I also think the idea of Optional is to provide some additional semantics. If
someone is happy using the shortcuts in queries then they should probably use
the same shortcuts in Java. It also means that they are probably not interested
in the additional semantics and should probably not use Optional in the first
place. Would you agree?
{quote}
I agree in principle, however it doesn't mean that you can't have a nicer
syntax for it. I believe that the idea is that if you are using {{Optional}}
you would use a more functional style {{map/filter}} instead of calling
{{isPresent()}} and {{get()}} -- but I'm not sure how this would apply to the
query; so you kind of have the shortcuts, might not be as good as in Scala or
other JVM language with more support for functional constructs, but it is still
there.
> 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&focusedCommentId=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] [Commented] (JDO-751) Support for Java8 Optional
[
https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140104#comment-15140104
]
Renato Garcia commented on JDO-751:
---
{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] Commented: (JDO-615) MetaData specification API
[
https://issues.apache.org/jira/browse/JDO-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732600#action_12732600
]
Renato Garcia commented on JDO-615:
---
Done. Patch attached with test and a possible fix ->
http://www.jpox.org/servlet/jira/browse/NUCCORE-338
> MetaData specification API
> --
>
> Key: JDO-615
> URL: https://issues.apache.org/jira/browse/JDO-615
> Project: JDO
> Issue Type: New Feature
> Components: api2, specification, tck2
>Reporter: Andy Jefferson
>Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 3
>
> Attachments: BooleanProperties.patch, jdometadata-6.patch,
> lower-case-d-in-metadata.patch, type-2.patch, type.patch
>
>
> We can specify MetaData via XML or annotations. The only way missing is via
> an API. I propose mirroring the XML structure with interfaces of the form
> public interface MetaData
> {
> addExtension(String key, String value);
> removeExtension(String key, String value);
> ...
> }
> public interface FileMetaData
> {
> addPackage(PackageMetaData pmd);
> ...
> }
> public interface PackageMetaData
> {
> addClass(ClassMetaData cmd)
> ...
> }
> public interface ClassMetaData
> {
> addField(FieldMetaData fmd)
> ...
> }
> public interface FieldMetaData
> {
> setInheritance(InheritanceMetaData inhmd)
> ...
> }
> and so on.
> We would then require a method on the PMF to register the metadata.
> If there are no objections to such a feature I'll propose a patch to try to
> provide all current JDO2 capabilities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-615) MetaData specification API
[
https://issues.apache.org/jira/browse/JDO-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732303#action_12732303
]
Renato Garcia commented on JDO-615:
---
Sorry, I should have said "MIGHT have been changed by mistake", and I couldn't
realize how to determine the defaults, in order to see if this was really wrong.
Well, this is an early access version, and by reading this thread it sounds
that the tests aren't ready yet. Besides that, I have a NPE from a autobox
conversion using DataNucleus(as you know, is the only implementation that is
2.3 compatible) which also doesn't have tests for this. So, 7 months isn't
making a lot of difference here I believe.
I'll post my finds at DN forums so you can take a look.
Thanks for your clarification anyway!
> MetaData specification API
> --
>
> Key: JDO-615
> URL: https://issues.apache.org/jira/browse/JDO-615
> Project: JDO
> Issue Type: New Feature
> Components: api2, specification, tck2
>Reporter: Andy Jefferson
>Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 3
>
> Attachments: BooleanProperties.patch, jdometadata-6.patch,
> lower-case-d-in-metadata.patch, type-2.patch, type.patch
>
>
> We can specify MetaData via XML or annotations. The only way missing is via
> an API. I propose mirroring the XML structure with interfaces of the form
> public interface MetaData
> {
> addExtension(String key, String value);
> removeExtension(String key, String value);
> ...
> }
> public interface FileMetaData
> {
> addPackage(PackageMetaData pmd);
> ...
> }
> public interface PackageMetaData
> {
> addClass(ClassMetaData cmd)
> ...
> }
> public interface ClassMetaData
> {
> addField(FieldMetaData fmd)
> ...
> }
> public interface FieldMetaData
> {
> setInheritance(InheritanceMetaData inhmd)
> ...
> }
> and so on.
> We would then require a method on the PMF to register the metadata.
> If there are no objections to such a feature I'll propose a patch to try to
> provide all current JDO2 capabilities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JDO-615) MetaData specification API
[
https://issues.apache.org/jira/browse/JDO-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12732091#action_12732091
]
Renato Garcia commented on JDO-615:
---
I think IndexMetadata.getUnique has been changed by mistake here
http://svn.apache.org/viewvc/db/jdo/branches/2.3-ea/api2/src/java/javax/jdo/metadata/IndexMetadata.java?view=diff&r1=737665&r2=724172&diff_format=u
/**
* Accessor for whether unique.
*
* @return Unique?
*/
-Boolean getUnique();
+boolean getUnique();
> MetaData specification API
> --
>
> Key: JDO-615
> URL: https://issues.apache.org/jira/browse/JDO-615
> Project: JDO
> Issue Type: New Feature
> Components: api2, specification, tck2
>Reporter: Andy Jefferson
>Assignee: Craig Russell
> Fix For: JDO 2 maintenance release 3
>
> Attachments: BooleanProperties.patch, jdometadata-6.patch,
> lower-case-d-in-metadata.patch, type-2.patch, type.patch
>
>
> We can specify MetaData via XML or annotations. The only way missing is via
> an API. I propose mirroring the XML structure with interfaces of the form
> public interface MetaData
> {
> addExtension(String key, String value);
> removeExtension(String key, String value);
> ...
> }
> public interface FileMetaData
> {
> addPackage(PackageMetaData pmd);
> ...
> }
> public interface PackageMetaData
> {
> addClass(ClassMetaData cmd)
> ...
> }
> public interface ClassMetaData
> {
> addField(FieldMetaData fmd)
> ...
> }
> public interface FieldMetaData
> {
> setInheritance(InheritanceMetaData inhmd)
> ...
> }
> and so on.
> We would then require a method on the PMF to register the metadata.
> If there are no objections to such a feature I'll propose a patch to try to
> provide all current JDO2 capabilities.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
