I want to state this proposal with the following respect of:

1.) the fact of keeping a grip on the api "bloat" factor.
2.) the fact that this scenario can be managed via the <class dynamic-update=""> property.
3.) the fact that this proposal coding time to implement may be exponential.

The Proposal

Add a <property update-strategies=""/> attribute and a new method Session.update( Object obj, String updateStrategy ).

Not to be confused with the already existing <property update="true|false"> attribute.

Note that the current Session.update() methods would still update all columns regardless of update-strategies.

My reasoning for this proposal vs "dynamic-update" is control of columns updated can actually be configurated via strategies/scenarios.

I can probably best explain by example:





Notice multiple strategies could be applied per property.

Then:

sess.update( itemMstr, "quantity-only" );

Only updates "quantity" column.

sess.update( itemMstr, "other-strategy" );

Would update "quantity" and "description" columns.

Note that the existing Session.update() methods would still update all columns regardless of update-strategies.

Please disregard the above proposal that I brought up.

After thinking it through and digging through source code, I don't think this could be implemted very easily, nor without adding memory overhead.

I don't see any clean cut way that the "udpate-strategy" updateable field properties can transition from the Session.update() to the Session.flush(). Also, if the entity gets updated() with two different strategies prior to being flushed - they would have to be combined - too messy.


Each class persister has a propertyUpdateability[] array that the <property update="true|false"/> sets at startup/config time. For my proposed "update-strategies" to work properly, each entity would also require its own propertyUpdateability[] array. Too much additional logic and memory overhead I feel.

Apologies for wasting the bandwith.

Well your idea is not bad at all. This is more or less similar to the different value objects generated by xdoclet. The problem he have is that our objects have some fields that are updated very often (almost every second) and some others that are updated maybe once a day. The class has around 30 fields. It happens also that those fields that are rarely updated have also a bigger size. Having all the fields with "update" on "true" was not acceptable because of performance issues. So eventualy we kept the fields that need frequent updates with "update=true", the others having to be updated using direct db access (ugly !).
I would be very interested if there is another smarter, cleaner solution(excepting defining 2 classes / or 2 config files that map on the same table).

use dynamic-update = true