[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16788992#comment-16788992 ] Andy Jefferson edited comment on JDO-652 at 3/10/19 6:00 PM: - If you get problems then you need to look in the LOG. It will tell you what the equivalent JDOQL string form is for a JDOQLTyped query, and it will also have a block about "QueryCompilation". That should be the same as the equivalent JDOQL string based query. That is where your debug starts. Then the log tells you the SQL invoked, for the single-string case and for the JDOQLTyped case. Should be the same if you have the same query. was (Author: andy): If you get problems then you need to look in the LOG. It will tell you what the equivalent JDOQL string form is for a JDOQLTyped query, and it will also have a block about "QueryCompilation". That should be the same as the equivalent JDOQL string based query. That is where your debug starts > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696196#comment-16696196
]
Tilmann Zäschke edited comment on JDO-652 at 11/22/18 6:47 PM:
---
I get a few compilation errors when trying to compile the generated
{{QOptionalSample}} class (after adding {{@PersistenceCapable}} to
{{org.apache.jdo.tck.pc.query.OptionalSample}}):
{code:java}
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[42,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[43,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[44,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[45,74]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[52,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[53,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[54,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[55,74]
error: cannot find symbol
{code}
It looks like it is creating expressions of type {{Optional}} while it
should should be {{Optional}} (or similar), for example in line 43:
{code:java}
this.optionalDate = new
ObjectExpressionImpl>(this, "optionalDate");
{code}
The class fields is (correctly) defined as:
{code:java}
public final ObjectExpression>
optionalDate;
{code}
Is there something else I should be doing?
was (Author: tilmann):
I get a few compilation errors when trying to compile the generated
{{QOptionalSample}} class (after adding {{@PersistenceCapable}} to
{{org.apache.jdo.tck.pc.query.OptionalSample}}):
{code:java}
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[42,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[43,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[44,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[45,74]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[52,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[53,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[54,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[55,74]
error: cannot find symbol
{code}
It looks like it is creating expressions of type {{Optional}} while it
should should be {{Optional}} (or similar), for example in line 43:
{code:java}
this.optionalDate = new
ObjectExpressionImpl>(this, "optionalDate");
{code}
The class fields is (correctly) defined as:
{code:java}
public final ObjectExpression>
optionalDate;
{code}
Is there something else I should be doing?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt,
>
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16696196#comment-16696196
]
Tilmann Zäschke edited comment on JDO-652 at 11/22/18 6:46 PM:
---
I get a few compilation errors when trying to compile the generated
{{QOptionalSample}} class (after adding {{@PersistenceCapable}} to
{{org.apache.jdo.tck.pc.query.OptionalSample}}):
{code:java}
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[42,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[43,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[44,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[45,74]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[52,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[53,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[54,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[55,74]
error: cannot find symbol
{code}
It looks like it is creating expressions of type {{Optional}} while it
should should be {{Optional}} (or similar), for example in line 43:
{code:java}
this.optionalDate = new
ObjectExpressionImpl>(this, "optionalDate");
{code}
The class fields is (correctly) defined as:
{code:java}
public final ObjectExpression>
optionalDate;
{code}
Is there something else I should be doing?
was (Author: tilmann):
I get a few compilation errors when trying to compile the generated
{{QOptionalSample}} class (after adding {{@PersistenceCapable}} to
{{org.apache.jdo.tck.pc.query.OptionalSample}}):
{code:java}
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[42,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[43,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[44,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[45,74]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[52,70]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[53,72]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[54,75]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample.java:[55,74]
error: cannot find symbol
{code}
It looks like it is creating expressions of type {{Optional}} while it
should should be {{Optional}} (or similar), for example in line 43:
{code:java}
this.optionalDate = new
ObjectExpressionImpl>(this, "optionalDate");
{code}
The class fields is (correctly) defined as:
{code:java}
public final ObjectExpression>
optionalDate;
{code}
Is there something else I should be doing?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt,
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676364#comment-16676364
]
Andy Jefferson edited comment on JDO-652 at 11/6/18 8:53 AM:
-
The problem with that remaining test is simply the difference between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
was (Author: andy):
The problem with that remaining test is simply the different between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt,
> JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675280#comment-16675280 ] Andy Jefferson edited comment on JDO-652 at 11/5/18 6:32 PM: - DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. QueryTest.executeJDOQLTypedQuery incorrectly only makes use of resultClass when deciding to call 'executeResultXXX'. It should also be looking at whether there is a result clause. There are also executeResultXXX methods that don't take in the result class (when that is not specified). No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api was (Author: andy): DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674473#comment-16674473 ] Michael Bouschen edited comment on JDO-652 at 11/5/18 4:11 PM: --- I checked in patch JDO-652-patch4.txt (see revision 1845744). With this checkin I see the following errors and failures: * query.conf: Failures: 5, Errors: 19 * jdoql.conf: Failures: 0, Errors: 10 The errors are because datanucleus does not implement the latest API changes (IfThenElseExperssion, min and max expressions, Map.get, String.startsWith). The failures are due to unexpected results of the test queries: * It looks like distinct is not working (see test class DistinctQuery). * The JDOQLTypedQuery API misses a way to specify the keys when the query is returing a map similar to the as clause in the single string version (see class ResultClassRequirements method testMap). Maybe we can add a method as(String name) to Expression. was (Author: mbo): I checked in patch JDO-652-patch4.txt (see revision 1845744). With this checkin I see the following errors and failures: * query.conf: Failures: 5, Errors: 19 * jdoql.conf: Failures: 0, Errors: 10 The errors are because datanucleus does not implement the latest API changes (IfThenElseExperssion, min and max expressions, Map.get, String.startsWith). The failures are due to unexpected results of the test queries: * It looks like distinct is not working (see test class DistinctQuery). * The JDOQLTypedQuery API misses a way to specify the kexs when the query is returing a map similar to the as clause in the single string version (see class ResultClassRequirements method testMap). Maybe we can add a method as(String name) to Expression. > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16675280#comment-16675280 ] Andy Jefferson edited comment on JDO-652 at 11/5/18 4:07 PM: - DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. Unless you mean just an alias for any result expression? in which case no objection to that, the DN internal code already has that, just not the public api was (Author: andy): DataNucleus has supported latest API changes for some time, you're just using the wrong version ... 5.1 is frozen (unless people provide backports), 5.2 is current. Issues with the tests from a cursory scan:- IfElseResult.testPositive2 uses "No Reviewer" instead of "No reviewer". NullResults.testDistinctNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testNavigation is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. NullResults.testUnique is not applying a result class to JDOQL single-string, but is to JDOQLTypedQuery. IfElseInFilter.testPositive0 applies an orderBy to JDOQL single-string but not to JDOQLTypedQuery. IfElseInFilter.testPositive1 doesnt set the JDOQLTyped argument (hence the error), and also omits to apply ordering to JDOQLTypedQuery. No idea what you mean by not being able to use a Map with JDOQLTyped ... you just specify the result class as a Map, like you'd do it as any other result class. > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson >Assignee: Michael Bouschen >Priority: Major > Fix For: JDO 3.2 > > Attachments: JDO-652-api-ifTheElse.txt, JDO-652-api-patch-Andy.txt, > JDO-652-patch4.txt, typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610265#comment-16610265
]
Andy Jefferson edited comment on JDO-652 at 9/11/18 8:25 AM:
-
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{code:java}
IfElseExpression ifExpr = query.ifElseExpression(Number.class);{code}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
was (Author: andy):
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{{IfElseExpression ifExpr = query.ifElseExpression(Number.class);}}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609833#comment-16609833
]
Michael Bouschen edited comment on JDO-652 at 9/11/18 6:12 AM:
---
I think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
was (Author: mbo):
IfElseExpressionI think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609833#comment-16609833
]
Michael Bouschen edited comment on JDO-652 at 9/10/18 9:58 PM:
---
IfElseExpressionI think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
was (Author: mbo):
IfElseExpressionI think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16608457#comment-16608457
]
Michael Bouschen edited comment on JDO-652 at 9/10/18 8:18 PM:
---
Thanks for the link Andy.
Following your proposal, I'm struggling with numeric types. Suppose I have an
Employee query with filter:
"this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)".
Then the JDOQLTypedQuery would look like
{noformat}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"), 15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{noformat}
But the expression "cand.salary.gt(ifExpr)" does not compile. The compiler
complains that there is not method gt taking a IfElseExpression. It
would compile if the gt argument would be of type IfElseExpression.
Do you have an idea?
was (Author: mbo):
Thanks for the link Andy.
Following your proposal, I'm struggling with numeric types. Suppose I have an
Employee query with filter: "this.salary > (IF (this.department.name ==
'Development') 15000.0 ELSE 25000.0)". Then the JDOQLTypedQuery would look like
{noformat}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"), 15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{noformat}
But the expression "cand.salary.gt(ifExpr)" does not compile. The compiler
complains that there is not method gt taking a IfElseExpression. It
would compile if the gt argumnet would be of type IfElseExpression.
Do you have an idea?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601154#comment-16601154
]
Andy Jefferson edited comment on JDO-652 at 9/2/18 12:52 PM:
-
Re: mail to jdo-dev mailing list (which I don't subscribe to, and besides this
is the issue in JIRA so ought to be the focal point for any dev discussion
specific to this API),
*IF-THEN-ELSE* : this was added to JDOQL after the JDOQLTypedQuery API was
designed. Consequently there is no handling for it. What QueryDSL does is
likely the best option to use as a guide for how to provide it (see
[http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/#d0e2105]
and
[http://www.querydsl.com/static/querydsl/4.1.4/apidocs/com/querydsl/core/types/dsl/CaseBuilder.html]
). Adapting it to JDO we could have something like this. Create a
CaseExpression via builder method on JDOQLTypedQuery
CaseExpression caseExpr = JDOQLTypedQuery.newCaseExpression();
and then have methods on CaseExpression to
CaseExpression when(BooleanExpression condition, Expression valueExpr);
CaseExpression else(Expression valueExpr);
Or go via the QueryDSL CaseBuilder idea? If you have a better idea, propose
something?
*Ordering NULLS FIRST/LAST* : again, not part of JDOQL when this API was
designed. So we could do something like this
OrderExpression
public enum OrderNullsPosition
{ FIRST, LAST }
/**
* Accessor for the position of nulls with this expression.
* @return The nulls position (or null if not defined)
*/
OrderNullsPosition getNullsPosition();
/**
* Method to set nulls to be ordered BEFORE non-nulls.
* @return The order expression
*/
OrderExpression nullsFirst();
/**
* Method to set nulls to be ordered AFTER non-nulls.
* @return The order expression
*/
OrderExpression nullsLast();
If you have a better idea, propose something?
*Map.get(Expression)* : Was only added to JDOQL later in the dev cycle, so
just add it?
*sqrt(), abs() etc for primitive wrappers* : A primitive wrapper is a
NumericExpression, so are already part of the API. You likely need
_datanucleus-jdo-query v5.0.6_ to see them, but that is not an error in the
API, just the implementation having them later.
*StringExpression.startsWith(String, int)* : Was only added to JDOQL later in
the dev cycle, so just add it. And while at it add the equivalent(s) taking in
StringExpression, and NumericExpression.
was (Author: andy):
Re: mail to jdo-dev mailing list (which I don't subscribe to, and besides this
is the issue in JIRA so ought to be the focal point for any dev discussion
specific to this API),
*IF-THEN-ELSE* : this was added to JDOQL after the JDOQLTypedQuery API was
designed. Consequently there is no handling for it. What QueryDSL does is
likely the best option to use as a guide for how to provide it (see
[http://www.querydsl.com/static/querydsl/4.1.3/reference/html_single/#d0e2105]
and
[http://www.querydsl.com/static/querydsl/4.1.4/apidocs/com/querydsl/core/types/dsl/CaseBuilder.html]
). Adapting it to JDO we could have something like this. Create a
CaseExpression via builder method on JDOQLTypedQuery
CaseExpression caseExpr = JDOQLTypedQuery.newCaseExpression();
and then have methods on CaseExpression to
CaseExpression when(BooleanExpression condition, Expression valueExpr);
CaseExpression else(Expression valueExpr);
Or go via the QueryDSL CaseBuilder idea? If you have a better idea, propose
something?
*Ordering NULLS FIRST/LAST* : again, not part of JDOQL when this API was
designed. So we could do something like this
ComparableExpression
/**
* Method to set nulls to be ordered BEFORE non-nulls.
* @return The order expression
*/
OrderExpression nullsFirst();
/**
* Method to set nulls to be ordered AFTER non-nulls.
* @return The order expression
*/
OrderExpression nullsLast();
OrderExpression
public enum OrderNullsPosition
{
FIRST,
LAST
}
/**
* Accessor for the position of nulls with this expression.
* @return The nulls position (or null if not defined)
*/
OrderNullsPosition getNullsPosition();
If you have a better idea, propose something?
*Map.get(Expression)* : Was only added to JDOQL later in the dev cycle, so
just add it?
*sqrt(), abs() etc for primitive wrappers* : A primitive wrapper is a
NumericExpression, so are already part of the API. You likely need
_datanucleus-jdo-query v5.0.6_ to see them, but that is not an error in the
API, just the implementation having them later.
*StringExpression.startsWith(String, int)* : Was only added to JDOQL later in
the dev cycle, so just add it. And while at it add the equivalent(s) taking in
StringExpression, and
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16547654#comment-16547654 ] Andy Jefferson edited comment on JDO-652 at 7/18/18 10:18 AM: -- Tried to apply some updates but cannot access "svn.apache.org" (via command line, or browser), svn: E170013: Unable to connect to a repository at URL '[http://svn.apache.org/repos/asf/db/jdo'] svn: E120108: Error running context: The server unexpectedly closed the connection. I can use svn to other sites, I can use Git to other sites. So presumably someone at Apache knows what those error codes mean; nothing in my logs. Blocked my IP ? Tried to upload a patch here (Firefox, also tried Chrome) and JIRA says "JIRA could not attach the file as there was a missing token. Please try attaching the file again." WTF? Glad we dumped JIRA from the DataNucleus project. I attach the proposed updates to the api project here in text form, since have no other way. The aim of this is to sort out some of the generics specifications of (some of) the JDOQLTyped expressions. Thx Index: src/main/java/javax/jdo/query/ComparableExpression.java === — src/main/java/javax/jdo/query/ComparableExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/ComparableExpression.java (working copy) @@ -28,7 +28,7 @@ * @param expr Other expression * @return Whether this is less than the other */ - BooleanExpression lt(ComparableExpression expr); + BooleanExpression lt(ComparableExpression expr); /** * Method returning whether this expression is less than the literal. @@ -42,7 +42,7 @@ * @param expr Other expression * @return Whether this is less than or equal the other */ - BooleanExpression lteq(ComparableExpression expr); + BooleanExpression lteq(ComparableExpression expr); /** * Method returning whether this expression is less than or equal the literal. @@ -56,7 +56,7 @@ * @param expr Other expression * @return Whether this is greater than the other */ - BooleanExpression gt(ComparableExpression expr); + BooleanExpression gt(ComparableExpression expr); /** * Method returning whether this expression is greater than the literal. @@ -70,7 +70,7 @@ * @param expr Other expression * @return Whether this is greater than or equal to the other */ - BooleanExpression gteq(ComparableExpression expr); + BooleanExpression gteq(ComparableExpression expr); /** * Method returning whether this expression is greater than or equal the literal. @@ -83,23 +83,23 @@ * Method to return a numeric expression representing the aggregated minimum of this expression. * @return Numeric expression for the minimum */ - NumericExpression min(); + NumericExpression min(); /** * Method to return a numeric expression representing the aggregated maximum of this expression. * @return Numeric expression for the maximum */ - NumericExpression max(); + NumericExpression max(); /** * Method to return an order expression for this expression in ascending order. * @return The order expression */ - OrderExpression asc(); + OrderExpression asc(); /** * Method to return an order expression for this expression in descending order. * @return The order expression */ - OrderExpression desc(); -} \ No newline at end of file + OrderExpression desc(); +} Index: src/main/java/javax/jdo/query/NumericExpression.java === — src/main/java/javax/jdo/query/NumericExpression.java (revision 1834479) +++ src/main/java/javax/jdo/query/NumericExpression.java (working copy) @@ -109,7 +109,7 @@ * Method to return a numeric expression representing the aggregated average of this expression. * @return Numeric expression for the average */ - NumericExpression avg(); + NumericExpression avg(); /** * Method to return a numeric expression representing the aggregated sum of this expression. @@ -209,4 +209,4 @@ * @return Bitwise XOR expression */ NumericExpression bXor(NumericExpression bitExpr); -} \ No newline at end of file +} was (Author: andy): Tried to upload a patch since cannot access "svn.apache.org" (via command line, or browser), svn: E170013: Unable to connect to a repository at URL '[http://svn.apache.org/repos/asf/db/jdo'] svn: E120108: Error running context: The server unexpectedly closed the connection. I can use svn to other sites, I can use Git to other sites. So presumably someone at Apache knows what those error codes mean; nothing in my logs. Blocked my IP ? Tried to upload a patch here (Firefox, also tried Chrome) and JIRA says "JIRA could not attach the file as there was a missing token. Please try attaching the file again." WTF? Glad we dumped JIRA from the DataNucleus project. I attach the proposed updates to the api project here in
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[ https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735201#comment-14735201 ] Andy Jefferson edited comment on JDO-652 at 9/8/15 5:53 PM: What remains on this issue : 1. spec : I don't mind contributing some text. The problem is that most of Ch14 is based around javax.jdo.Query. What I suggest would be updates to 14.1 to mention about JDOQLTypedQuery, an update to Ch14.5 to add the newJDOQLTypedQuery() method. Then insert a new section 14.10 before "Examples" to discuss solely the JDOQLTypedQuery interface. Finally update the "Examples" section to add some examples at the end. Other ideas? Alternately put the new section after examples, and have its examples inline with the various method descriptions. 2. tck : this needs tests. I am not the best person to write these since I've written the majority of the API, and the implementation. Volunteer? was (Author: andy): What remains on this issue : 1. spec : I don't mind contributing some text. What I suggest would be an update to Ch14.5 to add the newJDOQLTypedQuery() method. Then insert a new section 14.6 before "SQL Queries" to discuss solely the JDOQLTypedQuery interface. Finally update the "Examples" section to add some examples at the end. Other ideas? 2. tck : this needs tests. I am not the best person to write these since I've written the majority of the API, and the implementation. Volunteer? > Provision of a typesafe refactor-friendly query capability for JDOQL > > > Key: JDO-652 > URL: https://issues.apache.org/jira/browse/JDO-652 > Project: JDO > Issue Type: New Feature > Components: api, specification, tck >Reporter: Andy Jefferson > Fix For: JDO 3.2 > > Attachments: typesafe.patch, typesafe_manifest.patch > > > There are various querying capabilities of this type around. JPA2 has its > Criteria query API. Third party solutions like QueryDSL also exist, in its > case providing a JDOQL implementation (as well as JPQL, and HQL). We should > seriously consider introducing something along these lines in the JDO2.4 > timeframe. > There is a comparison of JPA Criteria with QueryDSL over at > http://source.mysema.com/forum/mvnforum/viewthread_thread,49 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
