Hi, On Wed, Nov 13, 2013 at 11:08 AM, Jukka Zitting <[email protected]> wrote: > Hi, > > On Wed, Nov 13, 2013 at 12:41 PM, Tobias Bocanegra <[email protected]> wrote: >> I quickly browsed through the code, and I could not find any >> mixin type that would allow adding a oak:index node. so how >> would you define an index on an arbitrary subtree? > > By adding such a mixin? > > The index code itself only cares about the presence of an oak:index > child node, not the type(s) of the parent node, so it doesn't really > matter if the node is added as a residual nt:unstructured node, or > through a mixin type that explicitly defines it. > >> suggest: >> * create a "oak:Indexable" mixin nodetype, > > +0 > >> * and make the oak:QueryIndexDefinition not extending from >> nt:unstructured, but define it properly. > > Personally I'd even do away with the oak:queryIndexDefinition type > entirely, and leave the typing (or lack of it) of index definitions to > the individual index plugins that interpret them. but then, we should at least define the mixin as a hint for the plugins of where to look for it:
[oak:Indexable] mix * oak:index (nt:base) this also rises the question: how does the index plugin find its definitions? certainly not via query :-) maybe by a lookup table in /jcr:system/oak:indexes ? > The reason why the type currently extends nt:unstructured is to allow > custom index plugins to support extra configuration that isn't > explicitly listed in the type definition. then, the index plugin should be able to provide the nodetypes it needs. -- toby
