> 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.
Andrus
This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 16:17:04 EST