Message Title

This is clearly a real problem. When adding the notion of fetch groups it looks like I only adjusted the reading of values (SELECT) for fetch-groups. Updates should only consider initialized attributes - I had assumed that was already the case, clearly it is not.

The same potential exists for property-based optimistic locking as well. We should verify that works with enhanced fetch groups as well.

As far as how to account for fetch groups in regards to updates, here is a relevant discussion from HipChat:

Gail Badner	regarding HHH-11155, what do you think about creating static strings for all the combinations of initialized lazy groups?
Gail Badner	as opposed to creating update strings dynamically
Steve Ebersole	not a fan tbh
Steve Ebersole	people already complain about the size of a SF
Steve Ebersole	perhaps we should consider some form of rolling cache
Steve Ebersole	FIFO style cache
Gail Badner	oh, so limit the size
Gail Badner	and add as needed
Steve Ebersole	it could be size
Steve Ebersole	it could be memory
Steve Ebersole	fifo (and lifo) just are styles of caching i call rolling
Steve Ebersole	its not a hard cache
Steve Ebersole	it has eviction
Steve Ebersole	with a "computeIfAbsent" semantic
...
Steve Ebersole	we'd maybe want this to integrate with cache provider anyway
Steve Ebersole	they'd have better eviction (the fifo part) control anyway
Steve Ebersole	its an idea I have been contemplating for a while
Steve Ebersole	we need to balance caching these Strings to avoid the computation with the resources needed to cache them
Steve Ebersole	some of the lockers e.g. we really ought to not cache until first use
...
Steve Ebersole	and I'd even consider squashing them into one Map/cache
Steve Ebersole	with a "smarter" key
Gail Badner	yeah, It would be nice to encapsulate a lot of the stuff in AbstractEntityPersister into some kind of cache object
Steve Ebersole	wrt the single Map/cache
Steve Ebersole	there is a balance there too
Steve Ebersole	the single Map saves additional Map creations
Steve Ebersole	but the "smarter" key means more instantiations even just to peek
Gail Badner	yeah, true

Basically there is a potentially huge explosion here in regards to the SQL update Strings we will need to keep now for enhanced entities with more than one fetch group. We want to make sure we balance caching those Strings (save computational resources, add potentially large memory overhead) versus recreating them each time they are needed.

Functionally a LRU style cache probably makes the most sense. I do worry a bit about the overhead of a LRU cache in regards to keeping the "recent access", which is why I suggested a FIFO cache.

Another option would be to treat all enhanced entities via dynamic-update, making sure that dynamic-update properly accounts for non-initialized lazy via enhancement attributes.