On Tue, 2003-02-11 at 10:53, Holger Hoffstätte wrote:
> 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.
I've submitted a feature request for this, as I think it will have
application beyond just our situation (not writing properties
unnecessarily is likely a good thing). There still remains the issue of
hasChanges not necesarily being "correct".
> > > > 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.
What do you need (two jar files, each with a different cayenne version,
plus the main driver?). If I can understand whats needed :-), I'll
likely put it all together for you.
> > > 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?
Craig
This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 19:01:37 EST