GenericValue store and dirty objects

[Bob Morley <rm...@emforium.com>]

One question that was posed to me today was why a store operation on a
GenericValue causes the database to get hit with a "basically" noop database
update.  A couple of things that were interesting:

- GenericEntity.set(...) will (unless value is null and null is ignored)
always run through logic that sets generatedHashCode = true, modified =
true, and notifies observers even if the value is identical.

- DelegatorImpl.store() will always call the implementation of
GenericHelper.store even if the GenericValue provided is marked as "not
modified".

What this means is that the client is responsible for doing its own "dirty
check" when going through attribute sets or pay the overhead of the
persistence work each time (as it can not rely on the modified flag).

So -- what is the thinking here?  Is this a matter of wanting to ensure that
EECAs and/or other observers get notified on the "intent to set" (even if
the old value = new value) ?  Do we want to ensure that the
lastModifiedDateTime gets updated even if the entity is not really changed
in any way?

If there are valid reasons for doing what it is doing (and I suspect there
is) then I want to propose that we offer a GenericValue.isDirty() that uses
the originalDbValues and the fields to determine if the GenericValue is
actually dirty.  If originalDbValues is null then it is dirty by default (a
new GV) and otherwise it would compare original vs. field (perhaps
considering the non-pks from the model?)
-- 
View this message in context: http://www.nabble.com/GenericValue-store-and-dirty-objects-tp25262566p25262566.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.