On Tue, 2003-02-11 at 10:17, Andrus Adamchik wrote:
> > This could be solved in three ways:
> > 1) Tapestry does the .equals() check and doesn't set the property if
> > it's still the same.
> > 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
> > 3) CayenneDataObject.writeProperty is modified to do the check.
> >
> > Does anybody else think that the semantics of hasChanges() requires
> > option 3 be taken? It does slightly degrade performance (maybe a lot,
> > if equals() turns out to be expensive for some types). Is it worth it,
> > or should it just be noted somewhere as an possible issue that has
> > possible workarounds (suggest 2 as an option)?
> >
> > What do y'all think?
>
> I would go with (2), since (3) has performance implications. Another idea
> though...
>
> 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.
Hmmm, DataContext calls hasChanges() early on in commitChanges to
quickly return if nothing needs to be done, so it may make the "quick"
return not so quick. But, if no-one else objects, I'll run with this
idea, cause it's better than the alternatives :-)
Craig
This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 16:29:09 EST