BTW, I believe your current implementation will NPE on a null o2 here: return ((BigDecimal) o1).compareTo((BigDecimal) o2) == 0;
On Fri, Jun 5, 2020 at 11:34 AM Michael Gentry <[email protected]> wrote: > Will adding this work? (Worked in a simple test I wrote.) > > public static boolean nullSafeEquals(BigDecimal o1, BigDecimal o2) > { > if (o1 == null || o2 == null) > return o1 == o2; > > return o1.compareTo(o2) == 0; > } > > Then delete the BigDecimal stuff from the other nullSafeEquals. (Revert > the changes.) > > > > On Fri, Jun 5, 2020 at 8: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 > >
