[jira] [Updated] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke updated JDO-751: Attachment: JDO-751-tck-patch-v3.txt New version of test. > 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-v3.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] [Updated] (JDO-751) Support for Java8 Optional
[ https://issues.apache.org/jira/browse/JDO-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tilmann Zäschke updated JDO-751: Attachment: (was: JDO-751-tck-patch-v2.txt) > 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 > > > 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)
Re: EmbeddedPCMapping cannot be cast to PersistableMapping
Hi, I like the use case for orElse(), that looks indeed useful. I added a test case for that. I switched to the latest m4-SNAPSHOT, that solves most of the problems. Two problems remain: a) Currently, "!(optionalPC.id == 88)" does not return objects with an 'empty' optionalPC field. I can't really tell whether this is correct or not. The spec says (14.6.2): "Navigation through a null-valued field, which would throw NullPointerException, is treated as if the subexpression returned false." If 'subexpression' means '!(optionalPC.id == 88)', the above behaviour is as intended. However, so far (in ZooDB) I interpreted 'subexpression' as the 'minimal' subexpression, i.e. 'optionalPC.id == 88' is the sub-expression. In this interpretation, the above query should also match all objects with an 'empty' optional field. I'm not sure which is correct. @Craig, @Michael, maybe you could clarify? b) the first test in orElse() now accepts orElse(), but fails with a NPE: testOrElse(org.apache.jdo.tck.query.jdoql.methods.SupportedOptionalMethods)java.lang.NullPointerException at java.lang.Class.isAssignableFrom(Native Method) at org.datanucleus.store.rdbms.sql.method.OptionalOrElseMethod.getExpression(OptionalOrElseMethod.java:61) at org.datanucleus.store.rdbms.sql.expression.SQLExpressionFactory.invokeMethod(SQLExpressionFactory.java:306) at org.datanucleus.store.rdbms.sql.expression.OptionalExpression.invoke(OptionalExpression.java:42) at org.datanucleus.store.rdbms.query.QueryToSQLMapper.processInvokeExpression(QueryToSQLMapper.java:3711) at org.datanucleus.store.rdbms.query.QueryToSQLMapper.processInvokeExpression(QueryToSQLMapper.java:3585) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.compilePrimaryExpression(AbstractExpressionEvaluator.java:213) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.compileUnaryExpression(AbstractExpressionEvaluator.java:182) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.compileAdditiveMultiplicativeExpression(AbstractExpressionEvaluator.java:161) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.compileRelationalExpression(AbstractExpressionEvaluator.java:136) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.compileOrAndExpression(AbstractExpressionEvaluator.java:78) at org.datanucleus.query.evaluator.AbstractExpressionEvaluator.evaluate(AbstractExpressionEvaluator.java:46) at org.datanucleus.query.expression.Expression.evaluate(Expression.java:338) at org.datanucleus.query.expression.DyadicExpression.evaluate(DyadicExpression.java:69) at org.datanucleus.store.rdbms.query.QueryToSQLMapper.compileFilter(QueryToSQLMapper.java:553) at org.datanucleus.store.rdbms.query.QueryToSQLMapper.compile(QueryToSQLMapper.java:429) at org.datanucleus.store.rdbms.query.JDOQLQuery.compileQueryFull(JDOQLQuery.java:887) at org.datanucleus.store.rdbms.query.JDOQLQuery.compileInternal(JDOQLQuery.java:347) at org.datanucleus.store.query.Query.executeQuery(Query.java:1883) at org.datanucleus.store.query.Query.executeWithArray(Query.java:1811) at org.datanucleus.api.jdo.JDOQuery.executeInternal(JDOQuery.java:369) at org.datanucleus.api.jdo.JDOQuery.executeWithArray(JDOQuery.java:268) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1257) at org.apache.jdo.tck.query.QueryTest.execute(QueryTest.java:1133) at org.apache.jdo.tck.query.QueryTest.executeAPIQuery(QueryTest.java:1069) at org.apache.jdo.tck.query.jdoql.methods.SupportedOptionalMethods.checkQuery(SupportedOptionalMethods.java:297) at org.apache.jdo.tck.query.jdoql.methods.SupportedOptionalMethods.testOrElse(SupportedOptionalMethods.java:312) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:284) at org.apache.jdo.tck.util.BatchTestRunner.doRun(BatchTestRunner.java:108) at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:148) at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:123) I'll upload the latest version to the JIRA. Cheers, Tilmann On 04-Jun-16 15:30, Andy Jefferson wrote: Hi, a) SQLSyntaxErrorException : Encountered "NOT" at line 1, column 185 Just seen your SQL generated. "WHERE NOT NOT (A0.OPTIONAL_PC IS NULL)" That is valid on some RDBMS but maybe Derby is throwing its toys out of the pram due to it? Current DN code will put brackets in there. i.e NOT (NOT (...)) b) optionalPC.get().id Released DN code only supports "optionalPC.get()" and not the access of fields of the dereferenced object (i.e it didn't do a join to the related table holding the object). Current DN code does however support
Re: EmbeddedPCMapping cannot be cast to PersistableMapping
Hi,
> a) SQLSyntaxErrorException : Encountered "NOT" at line 1, column 185
Just seen your SQL generated. "WHERE NOT NOT (A0.OPTIONAL_PC IS NULL)"
That is valid on some RDBMS but maybe Derby is throwing its toys out of the
pram due to it? Current DN code will put brackets in there. i.e NOT (NOT (...))
> b) optionalPC.get().id
Released DN code only supports "optionalPC.get()" and not the access of fields
of the dereferenced object (i.e it didn't do a join to the related table
holding the object). Current DN code does however support that.
As I mentioned previously, if having problems use nightly builds.
> c) Optional.orElse is currently not supported
Yes it is, and has been since DataNucleus v5.0.0-m4. You must be using an old
version.
Regarding a use-case for orElse, the test I use is putting the orElse in the
SELECT clause
Query q = pm.newQuery("SELECT id, stringField.orElse('NotPresent') FROM
mydomain.MyClass");
so I get back the value that is stored when it is set, or some other value if
not set (much like could be achieved with a CASE statement with other
datatypes).
Regards
--
Andy
DataNucleus (Web: http://www.datanucleus.org Twitter: @datanucleus)
[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=15315498#comment-15315498
]
Tilmann Zäschke commented on JDO-751:
-
As mentioned in the telecon, I found that the query {{"!(optionalPC != null)"}}
(where optionalPC is a field of type {{Optional}}) causes an SQL error:
{{java.sql.SQLSyntaxErrorException: Syntax error: Encountered "NOT" at line 1,
column 185.}}
The generated query looks as follows:
{{SELECT 'org.apache.jdo.tck.pc.query.OptionalSample' AS
NUCLEUS_TYPE,A0.ID,A0.OPTIONAL_DATE,A0.OPTIONAL_INTEGER,A0.OPTIONAL_STRING FROM
APPLICATIONIDENTITY0.OPTIONALSAMPLE A0 WHERE NOT NOT (A0.OPTIONAL_PC IS NULL)}}
This is presumably due to the {{NOT NOT}} near the end.
> 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 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=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.
