Speakers needed for Apache DC Roadshow
We need your help to make the Apache Washington DC Roadshow on Dec 4th a success. What do we need most? Speakers! We're bringing a unique DC flavor to this event by mixing Open Source Software with talks about Apache projects as well as OSS CyberSecurity, OSS in Government and and OSS Career advice. Please take a look at: http://www.apachecon.com/usroadshow18/ (Note: You are receiving this message because you are subscribed to one or more mailing lists at The Apache Software Foundation.) Rich, for the ApacheCon Planners -- rbo...@apache.org http://apachecon.com @ApacheCon
[jira] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16610265#comment-16610265
]
Andy Jefferson edited comment on JDO-652 at 9/11/18 8:25 AM:
-
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{code:java}
IfElseExpression ifExpr = query.ifElseExpression(Number.class);{code}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
was (Author: andy):
As I hinted at, you specified Double so java generics enforces Double, and Java
generics throws its toys out of the pram. If instead you did
{{IfElseExpression ifExpr = query.ifElseExpression(Number.class);}}
then it's fine.
You could look at updating ComparableExpression methods that take in
{code:java}
ComparableExpression{code}
to take in
{code:java}
ComparableExpression{code}
or something similar, to get around Java generics compilation nonsense.
Since (java.lang.)String and (java.util.)Date have no subtypes then their
associated Expression has no need of generics, whereas since (java.lang.)Number
has many subtypes and so its associated Expression does have need of generics.
Further to that we have a need to enforce type precision on some methods down
to the Double/Integer/Float level, such as
{code:java}
NumericExpression avg();{code}
hence it is either have generics on NumericExpression, or have to introduce
DoubleExpression, IntegerExpression, etc, and I don't want to go there.
As for naming, the reason it is called "IfElseExpression" (as opposed to
"IfThenElse") is that all expressions in that package are using the same naming
scheme ... XXXExpression. I've no problem with it being "IfThenElseExpression",
but maybe that is what Craig meant (and not calling it "IfThenElse" without the
Expression)?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [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] [Comment Edited] (JDO-652) Provision of a typesafe refactor-friendly query capability for JDOQL
[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16609833#comment-16609833
]
Michael Bouschen edited comment on JDO-652 at 9/11/18 6:12 AM:
---
I think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
was (Author: mbo):
IfElseExpressionI think we have two separate issues here:
(1) Builder method taking 1 or 3 arguments
(2) Type of the IfThenElse expression: extending DoubleExpression?
I think we can resolve (1) later, because issue (2) is much more important.
Maybe my comment from above was misleading. I tried to build a JDOQLTypedQuery
for "this.salary > (IF (this.department.name == 'Development') 15000.0 ELSE
25000.0)". I came up with the following code:
{code:java}
JDOQLTypedQuery query = getPM().newJDOQLTypedQuery(Employee.class);
QEmployee cand = QEmployee.candidate();
IfElseExpression ifExpr = query.ifElseExpression(Double.class);
ifExpr.ifThen(cand.department.name.eq("Development"),15000.0).elseEnd(25000.0);
query.filter(cand.salary.gt(ifExpr));{code}
For me this looks ok (not looking at issue (1)), but it does not compile. So I
played around with the generics in the interface IfThenElse, but I could not
find a working solution. So I'm not proposing that "IfThenElse" should extend
DoubleExpression. I was using the following interface definition:
{code:java}
interface IfThenElse extends ComparableExpression{code}
This supports IfTheElse and IfTheElse, too. But with Strings and
Dates we do not have the above issues.
cand.salary is of type NumericExpression. Maybe the issue is the
definition of NumericExpression:
{code:java}
interface NumericExpression extends ComparableExpression. {code}
So method gt in cand.salary.gt(ifExpr) expects an argument of type
ComparableExpression which is not compatiple with
IfElseExpression.
Andy, can you please try to compile the above query in your environment, just
to see whether you run into a similar issue? If so, do you have an idea how to
change the query API to make this working?
> Provision of a typesafe refactor-friendly query capability for JDOQL
>
>
> Key: JDO-652
> URL: https://issues.apache.org/jira/browse/JDO-652
> Project: JDO
> Issue Type: New Feature
> Components: api, specification, tck
>Reporter: Andy Jefferson
>Assignee: Michael Bouschen
>Priority: Major
> Fix For: JDO 3.2
>
> Attachments: JDO-652-api-patch-Andy.txt, JDO-652-patch3.txt,
> typesafe.patch, typesafe_manifest.patch
>
>
> There are various querying capabilities of this type around. JPA2 has its
> Criteria query API. Third party solutions like QueryDSL also exist, in its
> case providing a JDOQL implementation (as well as JPQL, and HQL). We should
> seriously consider introducing something along these lines in the JDO2.4
> timeframe.
> There is a comparison of JPA Criteria with QueryDSL over at
> http://source.mysema.com/forum/mvnforum/viewthread_thread,49
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
