On Tue, 2003-02-11 at 14:23, Andrus wrote:
> At 01:01 PM 2/11/2003 +1300, Craig Miskell wrote:
> > > > > 4) hasChanges() may "clean" fake modified objects internally on demand,
> > > > > i.e. when ObjectStore.hasChanges() finds a MODIFIED object, it will
> > > > > re-compare it with snapshot, and change it back to COMMITTED if the
> > > > > changes are not "real". This way we avoid unneeded overhead, and
> > achieve
> > > > > the correct behavior.
> > >
> > > Yes, this will most likely work, but something tells me that first marking
> > > objects and then later on reverting them 'magically' is not really a good
> > > idea, although right now I cannot think of a case where things might
> > > break.
> >I don't think it would change the state of the DataObjects back to
> >COMMITTED". Rather, hasChanges would simply not return true if the
> >object hadn't truly been modified. Of course, option 3 does avoid all
> >that messiness in the first place, but at what cost?
>
>
> Holger correctly pointed out one flaw in my original suggestion (4). No
> state changes should happen in such innocent-looking method like
> "hasChanges". So Craig's implementation of it above is much better.
Actually, I completely misread (meaning I didn't read it properly at
all) your original idea and thought that you had suggested what I said
:-)
> If this still looks unclean, I would suggest simply using custom class
> generation template with overriden writeProperty (which is probably option
> 2). I use custom templates with cgen ant task all the time. I think that
> eventually we must offer a set of standard templates in the Modeler, to
> tweak DataObject behavior. So implementing such template would still
> benefit Cayenne :-).
>
> I still think that changing the base implementation of writeProperty adds
> unneeded overhead.
I know Holger wanted to run OptimizeIt, but I wasn't sure what I was
doing so I just whipped up a very simple test case (DataObject class
with the two read methods and two write methods), and ran it through a
test harness with various objects (String, Number subclasses, Date),
writing a value 100,000,000 times in a row (actually 1/2 that number of
loops, writing two values in each loop.. see below). Repeated runs gave
very close times (within 10ms for each value type). There are three
runs, one using the current writeProperty code, the second using an
equals test but writing the exact same object repeatedly (both writes
per loop wrote the same object), and the third also using the equals
test, but writing two objects in the loop, resulting in the writes being
obj1, obj2, obj1, obj2...
Timings are as follows
Type Current code "Equals", same obj Equals alt obj
String 6594 7634 16164
Double 6793 7972 51223
Float 6794 7963 48169
Integer 6794 7973 17367
Date 6792 7971 9883
Boolean 6791 7967 17124
Average increase in time is 17% for the second version and this is with
the write method returning quickly because it sees the objects are
identical. When the objects are different, all hell breaks loose. The
above is enough to justify to me not to do the equals checking in
writeProperty. I'll do the hasChanges modification and see where that
leads.
Craig
This archive was generated by hypermail 2.0.0 : Tue Feb 11 2003 - 15:37:59 EST