[
https://issues.apache.org/jira/browse/JDO-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16676364#comment-16676364
]
Andy Jefferson edited comment on JDO-652 at 11/6/18 8:53 AM:
-------------------------------------------------------------
The problem with that remaining test is simply the difference between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100000000000000088817841970012523233890533447265625. This doesn't crop up
with single-string JDOQL since the string is embodied directly, so is parsed to
a BigDecimal with that String as input.
Workaround is to change your ifThenElse line to use the following arguments
cand.budget.mul(new BigDecimal("1.2"))
cand.budget.mul(new BigDecimal("1.1"))
hence equivalent BigDecimal literals to the string form. Passes for me if that
change is made.
was (Author: andy):
The problem with that remaining test is simply the different between
BigDecimal(1.1) and BigDecimal("1.1").
You pass in BigDecimal(1.1) and it is represented as a Literal with that value.
When the SQL is formed the literal has toString() called on it, hence on the
BigDecimal, and it comes across as
1.100000000000000088817841970012523233890533447265625. 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)
