|
|
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?)
|
Locked
