cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: SQL UPDATE fires on non-primitive values
Date Wed, 18 Jun 2014 13:21:29 GMT
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 ‘setXyz’, later on
> > during commit Cayenne should do a proper comparison and avoid “phantom”
> > commits. The relevant code is in
> > org.apache.cayenne.access.ObjectDiff.isNoop:
> >
> >
> >
> https://github.com/apache/cayenne/blob/master/cayenne-server/src/main/java/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 "==", but they are "equals".
> > > In the source I found in de PersistentObjectHolder.setValue the
> > following:
> > >
> > > Object oldValue = setValueDirectly(value);
> > > if (oldValue != value && relationshipOwner.getObjectContext() != 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
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message