Lukas Eder shows the importance of minimizing the scope of update statements:
Optionally, just as with JPA, you can turn on optimistic locking on this statement. The important thing here is that the
clicksandpurchasescolumns are left untouched, because they were not changed by the client code. This is different from JPA, which either sends all the values by default, or if you specify@DynamicUpdatein Hibernate, it would send only thelast_namecolumn, because whilefirst_namewas changed it was not modified.My definition:
- changed: The value is “touched”, its state is “dirty” and the state needs to be synched to the database, regardless of modification.
- modified: The value is different from its previously known value. By necessity, a modified value is always changed.
As you can see, these are different things, and it is quite hard for a JPA-based API like Hibernate to implement changed semantics because of the annotation-based declarative nature of how entities are defined. We’d need some sophisticated instrumentation to intercept all data changes even when the values have not been modified (I didn’t make those attributes public by accident).
I found this an interesting walkthrough of data layer-level mechanisms that directly affect database performance.