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.
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.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 20:24:31 EST