Re: Comparing BigDecimals

Yeah, I have special handling around BigDecimals to get around this. Later
on I generalized it a bit more to use Comparable.compareTo(other) == 0 to
mean there was no change. Besides BigDecimal I saw this same problem with
joda DateTime objects that had different time zones that worked out to be
the same moment in time.

I would probably recommend going with "instanceof Comparable" to be more
general, but I don't know if that would cause problems with certain
classes. It is working for me currently.


On Fri, Jun 5, 2020 at 7:47 AM Andrus Adamchik <[email protected]>
wrote:

> Hi folks,
>
> Just ran into an obscure and minor but at the same time fundamental bug -
> Cayenne generated unneeded updates when the only change is BidDecimal value
> scale [1]. Essentially for BigDecimals we shouldn't be calling
> "a.equals(b)" but use "a.compareTo(b) == 0". I have a fix [2], but using
> "instanceof" inside a common performance-sensitive code feels dirty. I'd
> much rather a comparison strategy to be a part of the PropertyDescriptor
> object or something. So not applying the PR just yet.
>
> Wanted to mention it here. Perhaps there are other data types that can't
> use "equals" for some reason. And perhaps there are other solutions to this
> problem too...
>
> Andrus
>
> [1] https://issues.apache.org/jira/browse/CAY-2660
> [2] https://github.com/apache/cayenne/pull/426