Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cayenne.apache.org
Received-SPF: pass (nike.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAHdRq59x7K3te7zAbM9oeaYhNwSkAy3+7y99ABO1s1z_A0bdbw@mail.gmail.com>
References: 
 <CAHdRq5-h-=AO40gOAsWAiiM3XDrj2+t_+3gZxEifdhgow2jHhg@mail.gmail.com>
 <82FB68B3-1D49-449F-A2A5-05CD48CF6B16@objectstyle.org>
 <CAHdRq59x7K3te7zAbM9oeaYhNwSkAy3+7y99ABO1s1z_A0bdbw@mail.gmail.com>
From: Michael Gentry <mgentry@masslight.net>
Date: Wed, 18 Jun 2014 09:21:29 -0400
Message-ID: 
 <CAA-upzpe_4mkCfHGb1A6R9FM2vQj+gp9ts6qGXba9aTq46SKfA@mail.gmail.com>
Subject: Re: SQL UPDATE fires on non-primitive values
To: Cayenne Users <user@cayenne.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2ca0c9488c904fc1c24c6

--001a11c2ca0c9488c904fc1c24c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mark,

We've encountered the scale issue before.  Our application uses Tapestry 5
for the front-end and Cayenne for the back-end.  We use a custom T5
Translator to convert all BigDecimal inputs on form submission to have a
scale of 3 in our application.  (T5 will use the custom translator to
convert String->BigDecimal before calling the the Cayenne setter.)  I don't
know if you can do something similar with your environment.

Also, I have a CayenneUtils class with an isDirty() method that does a deep
introspection of the modified/dirty Cayenne objects ignoring phantom
changes if that could be useful for you.

mrg


On Wed, Jun 18, 2014 at 8:56 AM, Mark Stobbe <markstobbe85@gmail.com> wrote=
:

> Thank you for the link to the code that does the check.
>
> I figured out that if two BigDecimal do not have the same scale, they are
> considered different. I guess that makes sense.
>
> When I retrieve BigDecimals from Cayenne it will have the correct scale
> set, but it does not set the scale of the new value before it compares.
> Is this something that Cayenne can solve?
>
> Mark
>
>
>
> On Wed, Jun 18, 2014 at 8:29 AM, Andrus Adamchik <andrus@objectstyle.org>
> wrote:
>
> > Actually even if an object is marked as dirty after =E2=80=98setXyz=E2=
=80=99, later on
> > during commit Cayenne should do a proper comparison and avoid =E2=80=9C=
phantom=E2=80=9D
> > commits. The relevant code is in
> > org.apache.cayenne.access.ObjectDiff.isNoop:
> >
> >
> >
> https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/jav=
a/org/apache/cayenne/access/ObjectDiff.java
> >
> > Andrus
> >
> >
> > On Jun 18, 2014, at 12:03 AM, Mark Stobbe <markstobbe85@gmail.com>
> wrote:
> >
> > > Hi,
> > >
> > > I have a decimal column which is translated to a BigDecimal. When the
> > value
> > > is equal to 0 and I set the value equal to 0 again, it will actually
> > > perform a SQL UPDATE. The two objects are "=3D=3D", but they are "equ=
als".
> > > In the source I found in de PersistentObjectHolder.setValue the
> > following:
> > >
> > > Object oldValue =3D setValueDirectly(value);
> > > if (oldValue !=3D value && relationshipOwner.getObjectContext() !=3D =
null)
> {
> > >
>  relationshipOwner.getObjectContext().propertyChanged(relationshipOwner,
> > > relationshipName, oldValue, value);
> > >  ..
> > > }
> > >
> > > Is this piece of code used for non-primitive properties?
> > >
> > > Mark
> > >
> > > PS: I am using 3.2M1
> >
> >
>

--001a11c2ca0c9488c904fc1c24c6--