[
https://issues.apache.org/jira/browse/OAK-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Davide Giannella updated OAK-6628:
----------------------------------
Fix Version/s: (was: 1.12.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.14.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
(v7.6.3#76005)
