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
