[ https://issues.apache.org/jira/browse/OAK-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Andrei Dulceanu updated OAK-6628: --------------------------------- Fix Version/s: 1.38.0 > More precise indexRules support via filtering criteria on property > ------------------------------------------------------------------ > > Key: OAK-6628 > URL: https://issues.apache.org/jira/browse/OAK-6628 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene > Reporter: Chetan Mehrotra > Priority: Major > Fix For: 1.36.0, 1.38.0 > > > For Lucene index we currently support indexRules based on nodetype. Here the > recommendation is that users must use most precise nodeType/mixinType to > target the indexing rule so that only relevant nodes are indexed. > For many Sling based applications its being seen that lots of content is > nt:unstructured and it uses {{sling:resourceType}} property to distinguish > various such nt:unstructured nodes. Currently its not possible to target > index definition to index only those nt:unstructured which have specific > {{sling:resourceType}}. Which makes it harder to provide a more precise index > definitions. > To help such cases we can generalize the indexRule support via a filtering > criteria > {noformat} > activityIndex > - type = "lucene" > + indexRules > + nt:unstructured > - filter-property = "sling:resourceType" > - filter-value = "app/activitystreams/components/activity" > + properties > - jcr:primaryType = "nt:unstructured" > + verb > - propertyIndex = true > - name = "verb" > {noformat} > So indexRule would have 2 more config properties > * filter-property - Name of property to match > * filter-value - The value to match > *Indexing* > At time of indexing currently LuceneIndexEditor does a > {{indexDefinition.getApplicableIndexingRule}} passing it the NodeState. > Currently this checks only for jcr:PrimaryType and jxr:mixins to find > matching rule. > This logic would need to be extended to also check if any filter-property is > defined in definition. If yes then check if NodeState has that value > *Querying* > On query side we need to change the IndexPlanner where it currently use query > nodetype for finding matching indexRule. In addition it would need to pass on > the property restrictions and the rule only be matched if the property > restriction matches the filter > *Open Item* > # How to handle change in filter-property value. I think we have similar > problem currently if an index nodes nodeType gets changed. In such a case we > do not remove it from index. So we need to solve that for both > # Ensure that all places where rules are matched account for this filter > concept -- This message was sent by Atlassian Jira (v8.3.4#803005)