I'm running into an interesting issue using Cayenne and Tapestry. We
have some forms with form fields directly hooked up (using OGNL) to the
properties of some DataObjects. When the form gets submitted, Tapestry
blithely sets the values of all the properties, whether they've changed
or not. Thus, Cayenne thinks the object is modified. At commit time,
this is handled somewhere (can't recall where), which checks snapshot
values vs current values using equals(), and ignores any changes which
aren't really changes (to the point of not generating sql for an object,
if none of it's properties have been changed). However, in the short
term, I'm calling DataContext.hasChanges() to see if there's any
modified objects, in order to enable/disable the save button. (The form
submit is not a commit, just a "next page please" kind of thing).
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?
Craig
This archive was generated by hypermail 2.0.0 : Mon Feb 10 2003 - 15:59:46 EST