On Fri, Nov 14, 2014 at 2:53 PM, Alex Parvulescu <alex.parvule...@gmail.com> wrote: > Add an index property on the definition? you can sort after reading all of > them, there won't be too many so performance is not a concern.
The IndexRules mentioned in [1] are read in the order they are listed. Later matching of NodeType to index rule is done in the order of the listing taking into account the inheritance. Map this xml config to JCR content I thought that same effect can be achieved via use of nt:unstructured. This seemed to be more intutive Using some ranking property ... well can be done yes but might not be intutive! On Fri, Nov 14, 2014 at 2:53 PM, Alex Parvulescu <alex.parvule...@gmail.com> wrote: > Can you post an example? How many levels down do you expect to have in a > definition? I would just convert the definition to an tree-like structure > made out of definitions, not content trees. Did not understand what you meant by tree like structures for definition. What needs to be supported is condition like below to determine the applicability of rules ancestor::*/@priority = 'high' Implementing such logic is easier via Tree as it allows access to ancestors. Further I was thinking to make use of Tree in aggregation logic also If making use of tree is so big a concern I can implement a similar structure which meets my requirement. I did implemented something similar but later realized that same thing can be met by Tree API and hence switched to that. Would not be much effort to resurrect it back! Chetan Mehrotra [1] http://wiki.apache.org/jackrabbit/IndexingConfiguration
