Handling Collection properties where getter returns unmodifiable collection

[jonl-percsolutions-com]

In DefaultResultSetHandler.instantiateCollectionPropertyIfAppropriate, of the propertyValue return is an instanceof an Unmodifiable collection, then a new collection should be called to be passed to the setter method, if it exists, instead of attempting to add objects to the unmodifiable collection.

OR

You should only use the collection returned by the getter in the case where a setter does not exist.

The reason for this is, the getter could return an unmodifiable collection, as in my case, or a collection that is not linked directly to the collection maintained by the owning object.

Ignoring the setter, when it exists, is ignoring the object design and Java Bean standard,breaking encapsulation, imo.

If an object doesn't have a "setter" you could also look for an addPropertyName method. Which would support allowing an object to manage it's own underlying collection.

My work around, currently, is to use a reference to the underlying backing collection to the property instead of the property name. However, I would like to be able to use a custom setter or adder instead of returning a direct reference to the underlying collection.

[emacarron]

Hi, that code already uses the getter to get the property if it exists:

Object propertyValue = metaObject.getValue(propertyName);

[jonl-percsolutions-com]

Yes, but in my case I have some logic in my setter to verify properties of an object and link them directly to the parent object. Data that is not necessarily stored in the database.

metaObject.getValue() returns an UnmodifiableList, which MyBatis then attempts to add objects to.

By acting on the returned collection from the getValue() method, instead of using the setter, after creating a collection, then MyBatis is assuming direct access to the authority collection. That is not what I desire.

It also appears that at different levels it does things differently, depending on how the collection is retrieved. In applyPropertyMappings() setValue is always called, after creating a new collection, but in applyNestedResultMappings, you are only instantiating a collection if the getter returns null.

So, it appears there is a slight inconsistency in design for top-level property mappings versus a nested mapping.

[emacarron]

Ok. I got it.

There is a reason for that apparent inconsistency. When handling a nested select we can create the full collection before injecting it to the bean, but when dealing with nested results the colection is filled row by row and we cannot hold a pointer to the parents collection because the parent may change. For example:

Parent Child
A 1
B 2
A 3

When reading row 3 and value 3 we need to locate the object A, get is collection (callling the getter) and add the new object 3.

So this is not a bug but how the algorithm works. It would get fixed if we finally implement #101 so I will keep it open.