Re: Modified but not modified

From: Holger Hoffstätte (holge..izards.de)
Date: Mon Feb 10 2003 - 16:53:29 EST

  • Next message: Craig Miskell: "Re: Modified but not modified"

    Craig Miskell wrote:
    > > > 1) Tapestry does the .equals() check and doesn't set the property if
    > > > it's still the same.

    I think this is the 'correct' solution since it makes someone else do the
    work, and Howard most likely will understand the problem.

    > > > 2) We write intermediate code (possibly overriding writeProperty in
    > > > order to do an equals() check) that avoids calling
    > > > CayenneDataObject.writeProperty if it's not a real change

    Work for you, no benefit for us. not good :-)

    > > > 3) CayenneDataObject.writeProperty is modified to do the check.

    IMHO the cleanest way. I cannot say how much of a performance hit this
    will cause, if any. I'm all for performance and usually the first to point
    out that many microoptimizations can make a great cumulative difference,
    but in this case it's probably OK.
    If someone can send me an easy-to-run benchmark (maybe the regression
    suite would be good?) I can run it through OptimizeIt. Alternatively
    there's a nifty free eclipse plugin that already works very well:
    http://eclipsecolorer.sourceforge.net/ unfortunately at the moment for
    Windows only, due to a required JVMPI dll.

    > > 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.

    Still, first of all I'd try to get Howard to change the
    property-plastering machinery. Tapestry 2.4 will make things even worse
    since it will supposedly copy all things back and forth constantly, so the
    less this thing does to our poor DataObjects, the better.. :)

    Holger



    This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 16:55:29 EST