[jira] [Commented] (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=16907580#comment-16907580 ] Michael Bouschen commented on JDO-652: -- Thanks Craig and Tilmann for the feedback. I changed the chapter according to the remarks and uploaded a new version to this JIRA. > 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: Ch14-Query.odt, 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.14#76016)
[jira] [Commented] (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=16907136#comment-16907136 ] Tilmann Zäschke commented on JDO-652: - I also had a look at the new Section in Ch14, looks good. Some minor comments: 14.10.1: * I think "chapter"is usually capitalized -> "Chapter" (2x) 14.10.3: * JDOTypedQuery should be JDOQLTypedQuery 14.10.6 * ComparableExpressions: Why is it called `geeq` instead of `gteq`? That seems inconsistent. Maybe even `gtEq` and `ltEq`? * NumericExpression: change "q query" to "a query" * NumericExpressions: missing ": " at end of line * "Persistent Fields" -> "Persistent fields" 14.10.7 + 8: * As mentioned by Craig, I think a different font for methods/variables may make reading the text easier: 'distinct', 'order by', 'ComparableExpression'. * Change "JDOQLTypedQuery method" to "The JDOQLTypedQueryMethod" (2x) * Change "Methods asc [...]" at beginning of sentence to "The methods asc [...]" 14.10.13 * Double space before JDOQLTypedQuery We should check the following in the generated PDF, because it looked different in LibreOffice than in OpenOffice: 14.10.3 + 7 + 8 + 10 + 11 * We need to double check the section headers in the generated document. It looks fine in OpenOffice, but in LibreOffice the "Typed Query Interface" and the other headers are not considered headers (just normal text) and have no numbering. 14.10.10 + 12 * Some of the lines have Times New Roman instead of Courier New font > 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: Ch14-Query.odt, 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.14#76016)
[jira] [Commented] (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=16904229#comment-16904229
]
Craig L Russell commented on JDO-652:
-
I'm looking at Ch14-Query.odt. Very nice.
p 35 the change around "ifgetColumnLabel" is hard to review so please check the
spacing.
p 37 "query using the query query API" query is duplicated.
p 37 to 41 we should try for consistency with the font used for java language
names (methods, interfaces, packages)
p 40 "JDOQLType query" should be {color:#00}JDOQLTypedQuery{color}
p 45 is there a missing cast for firstname to name here? "select firstname,
salary, manager as reportsTo"
Similar casts seem to be missing in several sections
> 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: Ch14-Query.odt, 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.14#76016)
[jira] [Commented] (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=16888284#comment-16888284 ] Michael Bouschen commented on JDO-652: -- Added Ch14-Query.odt with the work in progress of the new subchapter for typesafe queries (JDOQLTypedQuery). > 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: Ch14-Query.odt, 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.14#76016)
[jira] [Commented] (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=16834038#comment-16834038 ] Craig L Russell commented on JDO-652: - See the pull request > 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] [Commented] (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=16789018#comment-16789018
]
Michael Bouschen commented on JDO-652:
--
I checked the LOG. The JDOQL string form is for a JDOQLTyped query is OK, it is
the same as the JDOQL string based query. There is a difference in the result
handling. The result class instance is created w/o an constructor argument:
{{20:36:19,590 (main) DEBUG [DataNucleus.Query] - ResultObject of type
org.apache.jdo.tck.query.api.Michael$EmpWrapper created with following
constructor arguments: []}}
Here is the corresponding output from the JDOQL string based query:
{{20:36:19,021 (main) DEBUG [DataNucleus.Query] - ResultObject of type
org.apache.jdo.tck.query.api.Michael$EmpWrapper created with following
constructor arguments: [FullTimeEmployee(2, L., Craig, born 22/Dec/1975, phone
\{work=123456-2, home=}, hired 1/Jul/2003, weeklyhours 40.0, $5.0)]}}
> 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] [Commented] (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 commented on JDO-652: 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] [Commented] (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=16788917#comment-16788917
]
Michael Bouschen commented on JDO-652:
--
Thanks Andy.
I switched to Datanucleus SNAPSHOT and both queries testQuery15f and
testQuery16f compile. However they return an unexpected result. The result
class instances are created. They should wrap the selected FullTimeEmplyoee
instance, but instead the wrapped instance is null:
{{Wrong query result: }}
{{query: select into org.apache.jdo.tck.query.api.SampleQueries$EmpInfo from
org.apache.jdo.tck.pc.company.FullTimeEmployee where salary > :sal}}
{{expected: java.util.ArrayList of size 3}}
{{[EmpInfo(worker:Michael), EmpInfo(worker:Craig), EmpInfo(worker:Tillmann)]}}
{{got: java.util.ArrayList of size 3}}
{{[EmpInfo(worker:null), EmpInfo(worker:null), EmpInfo(worker:null)]}}
> 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] [Commented] (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=16786479#comment-16786479 ] Andy Jefferson commented on JDO-652: See https://github.com/datanucleus/datanucleus-api-jdo/issues/97 > 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] [Commented] (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=16785906#comment-16785906 ] Michael Bouschen commented on JDO-652: -- @[~andy]: The tck class SampleQueries include all the sample queries from chapter "14.10 Examples" of the spec. I started to implement a JDOQLTypedQuery version of all the sample queries. But I ran into issues for three queries: testQuery15f and testQuery16f both fail with the message "Cannot call executeResultList method when query has result unset. Call executeList instead.". Both queries try to store the result into a warpper class, but I hve no idea how to specify this with an JDOQLTypedQuery. testQuery19f uses a correlated subquery and I think we need an API extension for this, see JDO-778. Please take a look at branch JDO-652 on github to see my current version of class SampleQueries. Here the link: https://github.com/apache/db-jdo/blob/JDO-652/tck/src/main/java/org/apache/jdo/tck/query/api/SampleQueries.java > 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] [Commented] (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=16702351#comment-16702351
]
Tilmann Zäschke commented on JDO-652:
-
I simplified the problem a bit: Creating a simple class such as
{code:java}
package org.apache.jdo.tck.pc.query;
import java.util.Optional;
import javax.jdo.annotations.PersistenceCapable;
@PersistenceCapable
public class OptionalSample2 {
long id;
Optional optionalString;
}{code}
will cause {{mvn clean install}} to fail:
{code:java}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
on project jdo-tck: Compilation failure: Compilation failure:
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample2.java:[39,74]
error: cannot find symbol
[ERROR]
\projects\workspace-zoo\JDO-trunk-commit\trunk\tck\target\generated-sources\annotations\org\apache\jdo\tck\pc\query\QOptionalSample2.java:[46,74]
error: cannot find symbol{code}
@[~andy]: This appears to be a problem with Datanucleus (5.2.0-m2 /
dn-jdo-query-5.0.9). Would you mind having a look?
> 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] [Commented] (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=16698158#comment-16698158 ] Michael Bouschen commented on JDO-652: -- I forgot to mention that the problem (ClassCastException) with the cast Expression is solved using the latest DataNucleus version. > 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] [Commented] (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 commented on JDO-652:
-
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,
> 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] [Commented] (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=16682985#comment-16682985
]
Michael Bouschen commented on JDO-652:
--
I added some more test cases, because the new DataNucleus version supports
queries that ran into an Unsupported OperationException before.
However I still have a problem with a cast Expression. Suppose a query with the
following result:
{noformat}
query.setResult("MAX(((FullTimeEmployee)manager).salary)");{noformat}
I tried the following JDOQLTypedQuery code:
{noformat}
QFullTimeEmployee cast =
(QFullTimeEmployee)cand.manager.cast(FullTimeEmployee.class);
query.result(false, cast.salary.max());{noformat}
But it fails with an ClassCastException:
org.datanucleus.api.jdo.query.PersistableExpressionImpl cannot be cast to
org.apache.jdo.tck.pc.company.QFullTimeEmployee.
Any 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-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] [Commented] (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=16676376#comment-16676376 ] Michael Bouschen commented on JDO-652: -- Yup, I just figured out the same and checked in the change with the BigDecimals taking a string instead of a double (see revision 1845879). > 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] [Commented] (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 commented on JDO-652:
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] [Commented] (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=16675755#comment-16675755
]
Michael Bouschen commented on JDO-652:
--
Thanks for the feedback, I did not know that I have to use DataNucleus 5.2.
The test case issues are fixed.
I changed QueryTest.executeJDOQLTypedQuery to check both whether there is a
resultClass and/or a result clause specified in order to decide which
executeResultXXX method is called.
I also added a new method to Expression to define an alias for an expression:
{noformat}
/**
* Method to return an expression with the specified alias assigned to this
expression.
* @param alias the alias for this expression
* @return the expression with an alias
*/
Expression as(String alias);{noformat}
With the above changes there is only one error in query.conf, method
IfElseResult.testPositive1. Exceuting the query results in
{noformat}
ERROR 22003: The resulting value is outside the range for the data type
DECIMAL/NUMERIC(31,31){noformat}
This is the generated SQL query:
{noformat}
SELECT (CASE WHEN ((SELECT COUNT(*) FROM DATASTOREIDENTITY0.PROJECT_MEMBER
A0_SUB WHERE A0_SUB.PROJID = A0.DATASTORE_IDENTITY) > 2) THEN (A0.BUDGET *
1.1999555910790149937383830547332763671875) ELSE (A0.BUDGET *
1.100088817841970012523233890533447265625) END), A0.PROJID AS
NUCORDER0 FROM DATASTOREIDENTITY0.PROJECTS A0 WHERE A0.DISCRIMINATOR =
'org.apache.jdo.tck.pc.company.Project' ORDER BY NUCORDER0{noformat}
> 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] [Commented] (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 commented on JDO-652: 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] [Commented] (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 commented on JDO-652: -- 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] [Commented] (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=16651415#comment-16651415 ] Andy Jefferson commented on JDO-652: FYI, DataNucleus also now supports methods on geospatial types. http://www.datanucleus.org:15080/products/accessplatform_5_2/jdo/query.html#jdoql_typed_methods_geospatial though this requires use of the DN-provided "javax.jdo.jar" rather than Apache JDO "jdo-api.jar". Whether support for these types (and the associated query methods) can one day be standardised is left to people to request/discuss. The OGC standardised simple geospatial types a long time ago, as per [http://www.opengeospatial.org/standards/sfa] and DataNucleus has had full support for them since day one. These JDOQLTypedQuery expressions map directly on to the types they define. > 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] [Commented] (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=16639607#comment-16639607
]
Andy Jefferson commented on JDO-652:
If adding generics to the returned NumericExpression on those methods in
NumericExpression, suggest that log, exp ought to be NumericExpression,
certainly if cos, sin, tan etc are going to be.
As mentioned earlier, I would make the methods lt, gt, etc on
ComparableExpression take in
{{ComparableExpression expr}}
rather than just ComparableExpression. Hard to see if you have this change
given the number of patch files there
I have no particular preference on IfThenElse methods. What you have is fine by
me.
Separate issue : in recent source control tools we don't need to faff about
with patches; people can just have a separate branch to develop changes in and
then it is immediately visible what the overall API is. Also developers don't
need to leave their changes in separate files that others have to apply to be
able to see them; the branch can be downloaded and ran directly without
manipulation. Wouldn't that be a more convenient way of developing features?
Then, when it is agreed, the changes are just applied to the master branch. FWIW
> 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] [Commented] (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=16638767#comment-16638767 ] Michael Bouschen commented on JDO-652: -- Added a new patch Patch JDO-652-patch4.txt reflecting the current state of testing JDOQLTypedQuery instances. It includes the API changes that are part of JDO-652-api-ifTheElse.txt. Andy: what do you think about the API changes? In the interface IfThenElseExpression I used the method names "ifThen" and "elseEnd" instead of "when" and "otherwise", because I think they better match the builder method names in JDOQLTypedQuery. But if everybody else thinks "when" and "otherwise" are the better choice I'm open to change that. I also changed NumericExpression in order to solve my compilation problem with ifThenElse 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] [Commented] (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=16625126#comment-16625126
]
Michael Bouschen commented on JDO-652:
--
{panel}
Craig L Russell wrote:
Side question: what is the meaning of niladic sum() exp() and avg() applied to
NumericExpression?
{panel}
sum() and avg() are aggregate expressions. The other aggregate expressions are:
min() and max() in ComparableExpression and count() in Expression.
I think exp() is the natural exponential function, so e^x^ = x.exp().
log() is the natural logarithm function, so log~e~ x = ln x = x.log().
> 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-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] [Commented] (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=16622483#comment-16622483 ] Craig L Russell commented on JDO-652: - I very much like the current builder methods in ifThenElse patch. The builders that take literals and not class are very user-friendly. And I agree that the builder taking only class is not needed. And I like the names of the builders ifThen and elseEnd. Side question: what is the meaning of niladic sum() exp() and avg() applied to NumericExpression? > 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-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] [Commented] (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=16616793#comment-16616793 ] Michael Bouschen commented on JDO-652: -- I uploaded a new patch JDO-652-api-ifTheElse.txt extending the API as proposed. In the interface IfThenElseExpression I used the method names "ifThen" and "elseEnd" instead of "when" and "otherwise", because I think they better match the builder method names in JDOQLTypedQuery. But if everybody else thinks "when" and "otherwise" are the better choice I'm open to change that. I also changed NumericExpression in order to solve my compilation problem with ifThenElse expression. Please have a look. > 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-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] [Commented] (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=16613253#comment-16613253
]
Andy Jefferson commented on JDO-652:
I've updated the DN prototype to match Craig's ideas / namings, namely
*JDOQLTypedQuery* gains these methods
{code:java}
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type);
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @param ifExpr If expression
* @param ifValue Value to return when the if expression is met
* @param elseValue Value to return when the if expression is not met
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type, BooleanExpression
ifExpr, V ifValue, V elseValue);
/**
* Method to return an "IF (...) ... ELSE ..." expression for use in this query.
* @param type The type returned by the IfElse.
* @param ifExpr If expression
* @param ifValueExpr Expression for value to return when the if expression is
met
* @param elseValueExpr Expression for value to return when the if expression
is not met
* @return The IfThenElse expression
*/
IfThenElseExpression ifThenElse(Class type, BooleanExpression
ifExpr, Expression ifValueExpr, Expression elseValueExpr);
{code}
and there is now *IfThenElseExpression* as follows
{code:java}
public interface IfThenElseExpression extends ComparableExpression
{
/**
* Method to add an "IF (...) ..." clause.
* If called multiple times, will add extra "IF (...) ..." or "ELSE IF (...)
..."
* @param ifExpr The if expression
* @param value The return value
* @return This expression
*/
IfThenElseExpression when(BooleanExpression ifExpr, T value);
/**
* Method to add an "IF (...) ..." clause.
* If called multiple times, will add extra "IF (...) ..." or "ELSE IF (...)
..."
* @param ifExpr The if expression
* @param value The return value expression
* @return This expression
*/
IfThenElseExpression when(BooleanExpression ifExpr, Expression
valueExpr);
/**
* Method to add the "ELSE ..." clause.
* If called multiple times will replace the previous else clause
* @param value The return value
* @return This expression
*/
IfThenElseExpression otherwise(T value);
/**
* Method to add the "ELSE ..." clause.
* If called multiple times will replace the previous else clause
* @param value The return value expression
* @return This expression
*/
IfThenElseExpression otherwise(Expression valueExpr);
}
{code}
The builder methods provided don't cater for the cases where the user wants to
provide a literal for the "if" value and expression for the "else" value (and
vice versa), but i'd put those as minority interest use-cases.
> 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] [Commented] (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=16612876#comment-16612876
]
Craig L Russell commented on JDO-652:
-
{quote}Why would the builder method take 3 arguments? An "If-Else" can have
multiple "if"s and one "else". Specifying the "if-then" clauses individually
makes it more fluent IMHO.
{quote}
We can have builder methods for different use-cases. The most common is
probably one condition, with two alternative results. The builder method is on
the query object.
IfElseExpression expr =
q.ifThenElse(cand.department.name.eq("Development"), 15000.0, 25000.0)
Another example would be multiple conditions. The builder method is on the
query object, but the subsequent ifThen and ifElse methods are on the
IfElseExpression.
IfElseExpression expr =
q.ifThen(cand.department.name.eq("Development"), 15000.0)
.ifThen(cand.department.name.eq("Sales"), 65000.0)
.ifThen(cand.department.name.eq("Support"), 3000.0)
.ifElse(1.0);
Looking at the QueryDSL in DataNucleus, I'd be open to other names than
ifThenElse, ifThen and ifElse. Maybe "when" instead of ifThen, and "otherwise"
instead of ifElse.
{quote}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)?
{quote}
I was [confusingly] mixing the builder method with the type, which should match
the style of the other expressions, e.g. I'm fine with IfThenElseExpression or
IfElseExpression as the type. [IfThenElseExpression is probably more expressive
considering the tri-part nature of the functionality.] But imho the builder
method(s) would be more fluent if they omit the "Expression" part of the name.
> 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] [Commented] (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 commented on JDO-652:
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] [Commented] (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 commented on JDO-652:
--
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] [Commented] (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=16608775#comment-16608775 ] Andy Jefferson commented on JDO-652: And how is the Java API to know about "Number" when you define the type as "Double"? The "IfElseExpression" represents the type that it returns. You passed "Double" to the builder method, not "Number". Why would the builder method take 3 arguments? An "If-Else" can have multiple "if"s and one "else". Specifying the "if-then" clauses individually makes it more fluent IMHO. I can't see how "IfThenElse" can extend DoubleExpression ... because the type is "IfThenElse" ... i.e dependent on the type that it returns. And if the "If-Else" is returning a String? or a Date? IfElseNumeric, IfElseString and so on? (which makes it way less extensible). Why not provide some code that demonstrates how that will work (and preferably an implementation, to go in [https://github.com/datanucleus/datanucleus-api-jdo/blob/master/src/main/java/org/datanucleus/api/jdo/query/IfElseExpressionImpl.java] ) > 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] [Commented] (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=16608584#comment-16608584
]
Craig L Russell commented on JDO-652:
-
I'd much prefer IfThenElse as a name to IfElseExpression.
Also, have the "constructor" take three arguments: if, then, else. This makes
queries much more fluent. e.g.
IfThenElse ifExpr =
query.ifThenElse(cand.department.name.eq("Development"), 15000.0,
25000.0); query.filter(cand.salary.gt(ifExpr));
And as Michael says, have IfThenElse extend DoubleExpression
Or have the constructor be ifThenElse(Double.class,
cand.department.name.eq("Development"), 15000.0, 25000.0
> 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] [Commented] (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=16608540#comment-16608540 ] Michael Bouschen commented on JDO-652: -- Checked in API extensions: * Ordering NULLS FIRST/LAST * Map.get(Expression) * StringExpression.startsWith(String, int) Committed revision 1840429. > 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] [Commented] (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 commented on JDO-652:
--
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] [Commented] (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=16605781#comment-16605781
]
Andy Jefferson commented on JDO-652:
See
[https://github.com/datanucleus/javax.jdo/commit/34129e8c995db533545a1e882823edffd0a4c204]
for a prototype of If-Else handling. This means that you can write such as
the following
{{ JDOQLTypedQuery tq = pm.newJDOQLTypedQuery(Person.class);}}
{{ QPerson cand = QPerson.jdoCandidate;}}
{{ IfElseExpression ageGroupExpr =
tq.ifElseExpression(String.class);}}
{{ ageGroupExpr.ifThen(cand.age.lt(21), "Student");}}
{{ ageGroupExpr.ifThen(cand.age.ge(21).and(cand.age.lt(65)), "Worker");}}
{{ ageGroupExpr.elseEnd("Retired");}}
{{ tq.result(false, ageGroupExpr);}}
> 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] [Commented] (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 commented on JDO-652:
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 NumericExpression.
> 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] [Commented] (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=16596763#comment-16596763 ] Michael Bouschen commented on JDO-652: -- Added a new patch Patch JDO-652-patch3.txt reflecting the current state of testing JDOQLTypedQuery instances. > 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] [Commented] (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=16559995#comment-16559995 ] Andy Jefferson commented on JDO-652: In case you were expecting some DataNucleus version that uses/implements those methods, all DN nightly builds have had those methods for some time. > 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-patch2.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] [Commented] (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=16551995#comment-16551995 ] Michael Bouschen commented on JDO-652: -- Checked in the patch JDO-652-patch-Andy.txt (see revision 1836434). It includes the changes proposed by Andy: ComparableExpression, NumericExpression, StringExpression plus the corresponding changes in jdo-signatures.txt. > 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-patch2.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] [Commented] (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=16551781#comment-16551781 ] Michael Bouschen commented on JDO-652: -- I uploaded a new version of the patch file JDO-652-patch-Andy.txt. It now includes the method StringExpression.add(String); too. > 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-patch2.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] [Commented] (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=16549682#comment-16549682 ] Michael Bouschen commented on JDO-652: -- Added a new patch Patch JDO-652-patch2.txt reflecting the current state of extending the query test cases with JDOQLTypedQuery tests. > 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-patch2.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] [Commented] (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=16548828#comment-16548828 ] Andy Jefferson commented on JDO-652: About StringExpression.add(String); yes, add it. I've only added what I've come across that I've needed. All other methods have both options. > 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-patch.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] [Commented] (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=16548351#comment-16548351 ] Michael Bouschen commented on JDO-652: -- A question about the query interface StringExpression: It specifies a method add taking an Expression: StringExpression add(Expression expr); But I'm mising an add method taking a String: StringExpression add(String str); The method is used to add a string literal to a string field. Or is there a way to construct an Expression instance from a string, then I could use the existing add method. > 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-patch.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] [Commented] (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=16548344#comment-16548344 ] Michael Bouschen commented on JDO-652: -- Thanks for the updates. I was not able to create a valid patch file from your comment, because a lot of chars where changed by JIRA. But I could manually apply your changes to the two classes ComparableExpression and NumericExpression. The changes look good. I uploaded a patch file JDO-652-patch-Andy.txt with the changes, just for review. I propose I check in the changes, OK? > 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-patch.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] [Commented] (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 commented on JDO-652: 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 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 +} > 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-patch.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
[jira] [Commented] (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=16544587#comment-16544587 ] Michael Bouschen commented on JDO-652: -- Thanks for the hint! I have a few queries that return an unexpected result when running them as JDOQLTypedQuery (at least unexpected for me). I propose I check them in and add a pointer to the Jira where to find them. > 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-patch.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] [Commented] (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=16542799#comment-16542799 ] Andy Jefferson commented on JDO-652: FYI JDOQL "JDOHelper.getObjectId()" is PersistableExpression.jdoObjectId() JDOQL "JDOHelper.getVersion()" is PersistableExpression.jdoVersion() since they pertain to the object that we are requiring the "id" and "version" for. > 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-patch.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] [Commented] (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=16539211#comment-16539211 ] Michael Bouschen commented on JDO-652: -- Patch JDO-652-patch.txt is the first attempt to test JDOQLTypedQuery. It is not complete and is intended to discuss the approach to test JDOQLTypedQuery instances with the current query test framework (QueryElementHolder). > 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-patch.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] [Commented] (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=14904230#comment-14904230 ] Tilmann Zäschke commented on JDO-652: - Yes, that sounds good, and thanks for the link to Jinq. That is what I had in mind, except that they seem to load everything into the client first, which I think is not useful except for very small datasets... > 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)
[jira] [Commented] (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=14903067#comment-14903067 ] Andy Jefferson commented on JDO-652: If you want a better query API utilising Java 8 language features (and there are clearly lots of ideas around about how it could look, e.g Jinq) i'd encourage you to develop a proof of concept and ask for ideas as your concept starts to take shape - having something usable to visualise it is the best way of getting feedback. Feel free to clone the DN datanucleus-api-jdo and datanucleus-java8 plugins so it is readily visible, and if it comes to something it could initially become part of DN and then later JDO? i.e the same steps as we went through with the JDOQLTypedQuery. > 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)
[jira] [Commented] (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=14902690#comment-14902690
]
Tilmann Zäschke commented on JDO-652:
-
In https://issues.apache.org/jira/browse/JDO-749, ANdy wore in response to my
question about streams/lambdas in queries:
??And about yet another 'redesign' of the query API, we have waited nearly 3
years for this one from the provision of the DN TypesafeQuery API with little
input from others. Bear in mind that I wouldn't be contributing much time, so
if you want it then you need to provide time/ideas/implementations/tests.??
Sorry, I only really joined the discussions here a few months ago, I don't know
the history, but I certainly don't want to be disruptive.
I thought about streams/lambdas a bit more, and I think one key issue is that
the API will look very different from JDOQL or the proposed typesafe API, it
simply will have to look like the Java 8 stream API ({{filter()}},
{{reduce()}}, {{sort()}}, {{forEach()}}, ...).
Also, it will require considerable effort to even verify feasibility, I guess
at least another 6 months at least. The result may be that it actually doesn't
really work or makes sense.
I don't know what the JDO 3.2 timeline is, but I suspect it may be best to
follow through with the current proposal.
I suppose the disadvantage of duplicating the query at a later point with a
stream API is smaller than waiting for an API that may not even work. I guess
it boils down to the argument that having a 'very good' solution now is
preferable to potentially 'perfect' solution that may never come.
> 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)
[jira] [Commented] (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=14741115#comment-14741115 ] Craig L Russell commented on JDO-652: - Changing the structure of the specification would mean a really lot of work that I'm not sure is worth the effort. I'd suggest adding a section in Chapter 14 that deals with the new query strategy. I'll take a look at making the initial changes. > 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)
[jira] [Commented] (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=14736476#comment-14736476 ] Andy Jefferson commented on JDO-652: The other option to 1. spec is to create a new chapter 15 straight after "14. Query". The only problem is, I've no idea how these JDO_master.odm and the various chapters are linked, so if people prefer that then maybe someone who knows can create a start point for this new Chapter and I'll update it with the necessary description > 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)
[jira] [Commented] (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 commented on JDO-652: 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)
[jira] [Commented] (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-tabpanelfocusedCommentId=14574825#comment-14574825 ] Craig L Russell commented on JDO-652: - In order to make use of the new QueryExecution interface it will be useful to make the Query interface templated. T QueryT ... 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)
[jira] [Commented] (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-tabpanelfocusedCommentId=14547075#comment-14547075 ] Andy Jefferson commented on JDO-652: There are (at least) 2 options for the execution part. 1. Allow creation of Query on the PMF, PM, and then execute on the PM. Query q = pmf.createQuery(...) pm1.executeQuery(q); pm2.executeQuery(q); This has complications of the fact that the Query takes its FetchPlan from the PM that creates it (which may be modified from the default FetchPlan) yet with this has to start from a default FetchPlan, it means people will have to make large changes to their existing code (or use deprecated methods all over the place). 2. Create a Query like now, on the PM, and have the generic Query (what we have now) and the new JDOQLTypedQuery implement QueryExecutor. So we can have consistent execute methods across the Query and JDOQLTypedQuery. Not sure we can do the same with QueryDefinition (other than some of the basic getter/setter stuff) since the JDOQLTypedQuery will be using the javax.jdo.query.XXXExpression classes in its filter(), groupBy(), orderBy(), ... methods and the generic one uses Strings. For the first one, who has this use-case of requiring a Query to be useable across PMs? A JDO impl will cache the query+compilation already, PM can save it as named and access the named query in another PM. Other requirements ? * JDOQLTypedQuery.toString() should return the equivalent single-string JDOQL, so can be converted in that direction. * do we need to be able to convert from (JDOQL) single-string to JDOQLTypedQuery? SVN now has the JDOQLTypedQuery (and Subquery) added for reference/discussion. 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)
[jira] [Commented] (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-tabpanelfocusedCommentId=14539530#comment-14539530 ] Andy Jefferson commented on JDO-652: As already said, there are two parts to this. 1). Generation of a (JDOQL) query using Q classes in a typesafe manner. This revolves around the XXXExpression classes in the patch that was provided 4+ years ago. Since I have seen no negative comments on this unless something is received to the contrary soon then I will commit this in the next week (into the package javax.jdo.query). 2). The structure of the JDOQLTypedQuery class, and how it ties in to the query execution process. This needs to make use of whatever interface for QueryExecution so that a JDOQLTypedQuery can be executed using the same methods as a traditional Query. Personally I'm in favour of having a QueryExecution (or equivalent name) interface, and not changing too much more ... i.e let the user create a query like they do now pm.newQuery or pm.newTypedQuery and then execute them using methods in this interface, hence minimising the API change for users. 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)
[jira] [Commented] (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-tabpanelfocusedCommentId=14521437#comment-14521437 ] Andy Jefferson commented on JDO-652: In the patch, TypesafeQuery needs renaming to JDOQLTypedQuery, or JDOQLTypesafeQuery to reflect the fact that it is for JDOQL *only* (unlike javax.jdo.Query which can be used for any query language). 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)
[jira] [Commented] (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-tabpanelfocusedCommentId=13040897#comment-13040897
]
Craig L Russell commented on JDO-652:
-
I like the direction of this api. My comments here might have been expressed by
others; I don't claim ownership of them. ;-)
I like the naming of the Q classes generated during pre-processing. I consider
the requirement to have the persistent classes annotated to be a distraction
though.
I think we need to consider reuse of the query artifacts by different
persistence managers, and also the possibility that the query definition might
be stored as a named query. This leads to needing a factory defined on the PMF,
not just the PM. The factory might not be needed on the PM depending on other
considerations (discussed below).
The same query definition could be used by different projections. We could make
this explicit in the api by adding a method to the query definition that
returns a different interface like QueryProjectionR where R is the class of
the result. And the query definition interface contains a superset of the
methods of the query projection interface, reflecting that the default query
projection returns instances of the candidate class.
It isn't clear from the external view whether there is a check to be sure that
the filter applies to properties of the candidate class. I expect that we can
make sure that this is the case by templating the expressions on both the type
of the candidate class and the type of the property.
In order to execute a query, three things are needed: the query definition
(including the projection definition), the persistence manager, and the
parameters. I believe that there is value in allowing parameters to be bound
very late, during the execution of the query. But I also see value in allowing
parameters to be bound to a different instance entirely.
If set individually, properties should be type-checked as well. Using the
setParameter(name, value) method on the query definition, I don't see how to
check the type. Instead of name, perhaps a method taking the parameter itself
instead of the name.
It will be good to integrate this new query api into the existing query, but
I'll leave that discussion for later (perhaps once we agree what the new query
should look like).
Thinking out loud,
QueryDefinitionT extends QueryProjectionT {
void filter(PredicateT);
QueryProjectionP project(ClassP, projectionList...);
get/set Unmodifiable();
}
QueryProjectionP {
}
QueryExecutionP {
setParameter(ParameterQ, Q);
ListP executeList(Object... parameters);
P executeUnique(Object... parameters);
ListP executeList(Map parameters);
P executeUnique(Map parameters);
get/set ReadTimeout(int millis);
get/set WriteTimeout(int millis);
get/set Range(int low, int high);
get/set IgnoreCache(boolean);
get/set SerializeRead(boolean);
}
PersistenceManagerFactory {
...
QueryDefinitionT newQueryDefinition(ClassT candidateClass), boolean unique);
void storeNamedQuery(String name, QueryProjection? query);
QueryProjection? getNamedQuery(String name);
}
PersistenceManager {
...
ListP executeList(QueryProjectionP, Object... parameters);
P executeUnique(QueryProjectionP, Object... parameters);
QueryExecutionP newQueryExecution(ExecutionProjectionP);
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 maintenance release 1
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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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-tabpanelfocusedCommentId=13036690#comment-13036690 ] Andy Jefferson commented on JDO-652: Re: Query result specification There are two approaches ... constructor argument, or execute argument. If you do as constructor argument then you can't change the result class thereafter. With normal API you can change the result class/result definition after construction (i.e reuse Query objects). Consequently I don't see a sensible alternative to what is already there. Re: Parameter specification Why is it so important to pass the parameter values in to execute() ? Obviously we could add an argument (Map?, array?) to executeXXX() but I don't see an alternative to passing the result in also. What difference does it make if a parameter is state? 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 maintenance release 1 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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-tabpanelfocusedCommentId=13036377#comment-13036377 ] Michael Bouschen commented on JDO-652: -- I looked at the JDOQL typesafe query API. The expression syntax is looking good, but I have some questions about the handling of query parameters and specifying the query result. My concern is that the typesafe query API is using a very different aproach compared to the regular JDO queries. - Parameter handling: The typesafe query API uses a method setParameter to set the parameter value, meaning the parameters values are part of the state of the TypesafeQuery instance. With JDO queries parameter values are passed as arguments to the Query.execute call and not stored in the Query state. - Query result specification: The typesafe query API used a special execute method executeResultList to specify the query result, e.g. tq.executeResultList(String.class, false, cand.lastname). At first glance this looks like an execute call taking parameter values, but it is not. The reason might be, that this aproach allows tempating on the query result. An alternative would be specifying the query result type as a tempate argument of the TypesafeQuery instance, in addition to the candidate class. What do you think? 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 maintenance release 1 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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-tabpanelfocusedCommentId=13018356#comment-13018356 ] Matthew T. Adams commented on JDO-652: -- After discussing on the conf call Fri Apr 9, we considered the separation of the query definition from the persistence manager connected to which the query definition is executed. It became evident that there is a separation of concerns between the definition or criteria of the query and the PM against which it should execute. Instead of a TypesafeQueryT, perhaps the class could have a name that reflects the fact that it's a query definition, like TypesafeQueryDefinitionT, TypesafeQueryCriteriaT, or, considering that we're in Java and type safety is inherent, I'd move to drop the prefix Typesafe from the name and go with just something like QueryCritieriaT. The currently proposed Q classes could be called XxxCriteria (TeamCriteria in this example). It should also be abled to be obtained by the PMF or the PM. New PMF methods: // proposed new methods on PMF 1. T QueryCriteriaT newQueryCriteria(ClassT clazz); 2. Various overloads to execute the given QueryCriteria using the PM given by PMF.getPersistenceManagerProxy() New methods could be added to PM to allow for the execution of the query using that PM: // methods on PM 1. T QueryCriteriaT newQueryCriteria(ClassT clazz); 2. Various overloads to execute the given QueryCriteria using this PM. I see two options for methods that execute these queries. First, only put the execution methods (execute, update, delete) on the PM to keep the number of overloads down, or second, provide overloaded execution methods (execute, update, delete) on the QueryCriteria classes, one set of which takes a PM and delegates to its appropriate execution method, and another set of which does not take a PM and delegates to the PM given by PMF.getPersistenceManagerProxy(). The choice of which option comes down to how many overloaded methods there would be. Additionally, if such overloaded execution methods are provided on the QueryCriteriaT class, should the ones taking no PM execute against the PM returned from PM.getPersistenceManagerProxy() or, if the QueryCriteria was obtained from a PM, the PM from which it came? 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 maintenance release 1 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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-tabpanelfocusedCommentId=13018380#comment-13018380 ] Andy Jefferson commented on JDO-652: Re: Adding methods to PMF to define the query No problem with that (as mentioned before on the jdo-dev list some time ago). Re: Calling things XXXCriteria -1. This is a query, just like one formed from a single-string, or declarative API, in a form that can be executed. There is nothing in the dictionary definition of criteria that means it is somehow more suitable for this type of query. The difference to a single-string query, or a query generated by the declarative API is that is typesafe and refactorable. All queries (whether single-string,declarative, or via this API) have criteria. Just because some other API calls its API Criteria is not a reason in itself, and could be argued a reason not to, to avoid possible confusion. Re: putting methods on the PM Are you planning on doing that for a normal Query too? because they have no inherent need to be created from a PM either. Consistency please. 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 maintenance release 1 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (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-tabpanelfocusedCommentId=13018385#comment-13018385 ] Matthew T. Adams commented on JDO-652: -- Before I forget, there was another issue about how bulk update delete affect any callbacks that PC classes or listeners may implement. We discussed on the call that it would be beneficial for the developer to make a conscious decision to decide whether or not instance or listener callbacks should be invoked by requiring all of the bulk update(..) and delete(..) methods to take a boolean indicating whether callbacks should be invoked or not. This would also be a new feature for the existing deletion by query feature, since the specification currently requires that predeletion callbacks be invoked. In this way, the developer is required to tell JDO that he knows about the callbacks and either wants or doesn't want to subvert the object model. 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 maintenance release 1 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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-tabpanelfocusedCommentId=12993882#comment-12993882 ] Andy Jefferson commented on JDO-652: Any comments ? Everyone ok with this being checked in as-is ? ;-) 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 maintenance release 1 Attachments: typesafe.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 is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (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-tabpanelfocusedCommentId=12930021#action_12930021 ] Andy Jefferson commented on JDO-652: Blog entry comparing JDO Typesafe against JPA Criteria http://datanucleus.blogspot.com/2010/11/jdo-typesafe-vs-jpa-criteria.html 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12930148#action_12930148 ] Matthew T. Adams commented on JDO-652: -- I admit to not having followed the design discussions too closely, but there was one line that tripped me up when reading your blog. It was the last example, that of a subselect: /* 1 */ TypesafeQueryProduct tq = pm.newTypesafeQuery(Product.class); /* 2 */ QProduct cand = QProduct.candidate(); /* 3 */ TypesafeSubquery tqsub = tq.subquery(Product.class, q); /* 4 */ QProduct candsub = QProduct.candidate(q); /* 5 */ ListProduct results = tq.filter(cand.value.lt(tqsub.select(candsub.value.avg(.executeList(); On line 3, I expected to see TypesafeSubquery as a generic declaration, TypesafeSubqueryProduct. I realize that that since it's coming from its superselect instance (of type TypesafeQueryProduct), the subselect can know the type of the candidate class of its superselect. Question 1: Why is the declaration not TypesafeSubqueryProduct? Question 2: If the subselect queries the same candidate class as the superselect, could we not provide an overload for TypesafeQueryT's subquery method that has the signature TypesafeSubqueryT subquery(string name)? 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12930149#action_12930149 ] Matthew T. Adams commented on JDO-652: -- Small name change suggestion. Instead of the term TypesafeQuery, how about TypedQuery? The fact that it's type-safe is implicit by virtue of its being typed. Saying that it's typed is sufficient. 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12929579#action_12929579 ] Matthew T. Adams commented on JDO-652: -- Andy wrote: 1. Naming convention for generated Query classes. Currently prefixed by Q in this prototype 2. Way of obtaining candidate, parameter, variable, subquery. If the user wants to access a field then they need to cast to the expression type. See the blog entry for details. Ideally would like to avoid casting - RE 1: My personal recommendation for the the Query classes is to append the word Query to end of the type. Instead of QProduct, it would be ProductQuery. RE 2: I've been following your blog entries on this development work, and I agree on avoiding casting. Would it be possible to provide a method in the Q class that the user can call instead of casting? Perhaps a getField() method in the right place that returns a java.lang.reflect.Field. I'm not sure where the right place is yet, but in that method, the cast can take place and at least the user wouldn't have to do any casting. Thoughts? 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12929581#action_12929581 ] Andy Jefferson commented on JDO-652: Thx for your feedback Matthew. I actually updated DN SVN this morning with some changes for casting, and also the most recent blog entry examples to match. The casting isn't there now (at least on the examples I've worked through). The main things on this change are * use static method on Query class to get the candidate. * use static method on Query class to get variable of that type * use xxxParameter methods on TypesafeQuery to get the XXXExpression for the parameter (e.g stringParameter(paramName), doubleParameter(paramName). * multiple select() methods on TypesafeSubquery so we can get the correct XXXExpression there too. Step in the right direction at least 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12929318#action_12929318 ] Andy Jefferson commented on JDO-652: Javadocs for what is proposed to be javax.jdo.query are at http://www.datanucleus.org/javadocs/core/2.2/org/datanucleus/query/typesafe/package-summary.html DN SVN trunk (and soon to be 2.2 M3) now has a functioning JDOQL typesafe query API. Amongst the areas to discuss 1. Naming convention for generated Query classes. Currently prefixed by Q in this prototype 2. Way of obtaining candidate, parameter, variable, subquery. If the user wants to access a field then they need to cast to the expression type. See the blog entry for details. Ideally would like to avoid casting 3. Can we extend it to provide something for JDOQL *and* JPQL. That is, make use of the language argument that JDO typically accepts on queries (not implemented in the prototype) and have TypesafeJDOQLQuery, TypesafeJPQLQuery (for example). 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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-tabpanelfocusedCommentId=12927451#action_12927451 ] Andy Jefferson commented on JDO-652: Some examples of what you can do with DataNucleus prototype API http://datanucleus.blogspot.com/2010/11/jdo-typesafe-queries-part-3-examples.html 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 maintenance release 1 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 is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
