[
https://issues.apache.org/jira/browse/OFBIZ-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14043633#comment-14043633
]
Adam Heath commented on OFBIZ-5331:
-----------------------------------
Ok, bad news. Can't apply this patch at this time. But not for the reasons
you might think. The method it is updating is too buggy, and needs to be fixed
first.
The first bug fouind was that doing compareRelationalOperator("abc", null) will
throw an NPE. This is because that's how compareTo is defined. This is an
obvious bug, but it does *not* have an obvious fix. See the next issue.
In SQL, a NULL is special. NULLs are not like anything. NULL = NULL returns
NULL, NULL != NULL returns NULL, and the same goes for all the other operators.
It's not exactly intuitive. For instance, in ORDER BY, one can request NULLs
to be first, or last. So, you might think they have a sensible place in a
comparison operator. However, in SQL, a NULL on any side of the operator will
make the operation return NULL.
This kind of SQL handling of NULL is not the way the condition system in ofbiz
works. It expects a boolean(not Boolean). This could cause subtle issues, and
I want to fix those first.
> Change EntityComparisonOperator to use compareTo()
> --------------------------------------------------
>
> Key: OFBIZ-5331
> URL: https://issues.apache.org/jira/browse/OFBIZ-5331
> Project: OFBiz
> Issue Type: Improvement
> Components: framework
> Reporter: Joe Eckard
> Priority: Trivial
> Attachments: patch.txt
>
>
> The methods compareEqual() and compareNotEqual() both use equals() instead of
> compareTo() which can be problematic when used to compare BigDecimal objects.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
