Major Description
this morning we discussed a case where adding an oak:index child node somewhere in the hierarchy was not doable because the target node was restrictive in the types of children that can be added (presumably nt:folder or similar).
Instead of suggesting to move the index definition up to the root node when the index is actually just needed for the sub-tree, we could fix the situation by shipping oak with a dedicated mixin type that makes an node being able to define it's own oak:index child.
The mixin type could look as follows:
[oak:Indexable] mixin + oak:index (nt:base) = nt:unstructured COPY
The definition above means:
- any node holding mixin type oak:Indexable can hold an optional node called oak:index
- this node can have any primary type
- but the default primary type if not specified otherwise (i.e. when calling parent.addNode("oak:index")) would be nt:unstructured.
- if desired however, calling parent.addNode("oak:index", "oak:Unstructured") would equally work (as any other primary type
- the COPY flag indicates that the oak:index node would be copied into the version storage if the parent was versionable and checkin was called.
NOTE: I am not totally sure OPV flag COPY is really desired here... but it reflects what we are having today with the oak:index node stored with the root node. maybe that worth a second thought, if we really want the tree defined by oak:index to be copied into the version storage upon every call to VersionManager.checkin; I am not too familiar with the indexing to decide whether that makes sense or not... from a distant point of view OPV IGNORE might equally make sense.