You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Davide Giannella (JIRA)" <ji...@apache.org> on 2019/06/04 15:35:09 UTC

[jira] [Updated] (OAK-6628) More precise indexRules support via filtering criteria on property

     [ 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: 1.16.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, 1.16.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)