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