UnIndex: surprising behaviour if more than a single attribute is indexed

[d-maurer]

UnIndex suggests that it can index a document under several attributes (--> indexed_attrs).
However, it does not document what this means.

The current implementation effectively uses at most one attribute for any given object -- the last one in indexed_attrs for which the object has a value.

I do not think that this behaviour is intensional:

• index_object iterates of indexed_attrs and updates _index and _unindex for each attribute for which the object has a value - with later attributes undoing the update of former ones; one could get the same effect without successive updates
• it would be more natural that the first attribute with a value succeeds (rather than the last one).

I suggest to clearly document what indexing under several attributes should mean and ensure that the implementation follows (naturally) the intension.

[andbag]

I agree with you. I had already wondered about this behavior. If it should be changed, also the CompositeIndex must be adapted accordingly.

Products.ZCatalog/src/Products/PluginIndexes/CompositeIndex/CompositeIndex.py

Line 250 in dd30d44

def _get_component_keywords(self, obj, component):

[d-maurer]

Andreas Gabriel wrote at 2019-3-28 13:34 -0700:

I agree with you. I had already wondered about this behavior. If it should be changed, also the CompositeIndex must be adapted accordingly. https://github.com/zopefoundation/Products.ZCatalog/blob/dd30d4413eb1090f2a05bb4cfe438dc0a9690611/src/Products/PluginIndexes/CompositeIndex/CompositeIndex.py#L250

There is another suboptimal thing with `UnIndex`: it applies its `_convert` method on searching but not on indexing. In general, it is adviceable to process the values for indexing in the same way as those for searching - otherwise, there is a risk that searches give surprising results. The `_convert` of `UnIndex` is the identity. Thus, we do not see a true error. However, if `UnIndex` would employ `_convert` homogenously (both during indexing as well as during searching), then (e.g.) `DateIndex` could define its own `_convert` and use everything else from `UnIndex/FieldIndex`.