[Hibernate-devel] Collection Wrappers (was:volunteers?)

[Gavin_King/Cirrus%<CI...@ci...>]

> In map.entrySet() you have a comment about wrapping proxies around the
> Map.Entry instances in the set. I don't see why this is necessary. The
> only affective operation on Map.Entry is setValue(); you can't change
> the key. Therefore I don't see any way to use it to change the
> structure of the map. You must use the iterator itself to remove
> elements. So, I implemented this differently in SortedSubMap; if you
> agree, we should change Map#entrySet().

entrysets support "element removal, which removes the corresponding mapping
from the map, via the Iterator.remove, Set.remove, removeAll, retainAll and
clear operations". Also we do need to worry about catching setValue().

I think. Am I wrong?

The less-than-satisfactory present solution is to assume that if they
accessed the entryset, they are going to change something.


> Neither Map nor SortedMap copy the maps supplied in the contructor the
> way the Set and SortedSet do. Is this necessary?

Very Good Question. I added it to Set + SortedSet as an afterthought today.
I think SortedMap and Map also need it. I havn't fully thought this stuff
through and I guess a certain point of view would be not to worry about it:

Suppose the application passes a subset to hibernate to persist. Hibernate
wraps it up and tracks changes to it by catching invocations on the
wrapper. The application might later on (in the same Session, but after a
flush) change the original set, which changes the subset. But hibernate
wouldn't know. Well, unfortunately it sometimes _would_ know. Which makes
the behaviour very undefined. If we _copy_ the original subset, then at
least we know that changes to the original set will _never_ be reflected
in the persistent set.

Now an alternative approach is to just declare "dont try to persist
subsets,
dont try to alter a Map via an entryset or keyset that you created earlier,
etc." The way I envisage that all this functionality will actually be
_used_
by a real application suggests that we shouldn't worry *too* much about
these
more exotic usages...

I do not have a strong opinion about any of this yet.

An alternative (slower) approach might be to fully diff all collections
against their persistent state (this only happens with arrays now and is
somewhat harder to implement for Sets and Maps). The thing is that lazy
initialization requires this cool wrapper class and I'm keen to make use
of it to save time diffing as well.