[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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<Number> 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<Number> 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(10000.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)
