Ah, I was too focused on compareTo() which doesn't handle nulls... :-)
On Tue, Jun 9, 2020 at 8:15 AM Andrus Adamchik
wrote:
> It should not. "instanceof" takes care of weeding out nulls.
>
>
> > On Jun 9, 2020, at 3:11 PM, Michael Gentry wrote:
> >
> > BTW, I believe your current implementat
It should not. "instanceof" takes care of weeding out nulls.
> On Jun 9, 2020, at 3:11 PM, Michael Gentry wrote:
>
> 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 M
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 wrote:
> Will adding this work? (Worked in a simple test I wrote.)
>
> public static boolean nullSafeEquals(BigD
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 n
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
th
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
