[
https://issues.apache.org/jira/browse/OFBIZ-6386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15335689#comment-15335689 ]
Gareth Carter commented on OFBIZ-6386:
--------------------------------------
{quote}
Mini-language is a scripting language. One of the nice things about scripting languages is you can compare things like decimal values without worrying about the underlying implementation. That is what the current implementation does: 2 == 2.0 == 2.000000.
{quote}
is not quite true in the my opinion. In minilang, field type conversion and comparison defaults to string representation unless you explicitly define the type, string comparison and numerical comparison are different. When it comes to comparing BigDecimals, information is lost (ie scale is changed, lowered) so values that are not the same can be interpreted to be the same (check attached image). Example, 2.01 == 2.001 when using <if-compare, value 2.001 is scaled down and rounded up yielding result 2.01.
The patch does not compare precision but if the minilang does then yes it will be an issue. But I suspect 99% cases, do not care about it
> compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly
> -------------------------------------------------------------------------------------------------------------
>
> Key: OFBIZ-6386
> URL:
https://issues.apache.org/jira/browse/OFBIZ-6386> Project: OFBiz
> Issue Type: Bug
> Affects Versions: Trunk
> Reporter: Gareth Carter
> Assignee: Mridul Pathak
> Priority: Minor
> Attachments: compareBigDecimals.png, v1.patch, v2.patch
>
>
> Moving the conversation from OFBIZ-6291 to this issue.
> compareBigDecimals scales down and rounds up meaning you lose information and the comparison result is not as expected
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Locked
