Re: Modified but not modified

From: Andrus (andru..bjectstyle.org)
Date: Mon Feb 10 2003 - 20:23:14 EST

  • Next message: Andriy Shapochka: "new commitChanges(...)"

    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