jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chetan Mehrotra (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6628) More precise indexRules support via filtering criteria on property
Date Tue, 12 Sep 2017 15:56:02 GMT

    [ https://issues.apache.org/jira/browse/OAK-6628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16163154#comment-16163154

Chetan Mehrotra commented on OAK-6628:

This looks better and enables future extensions

> 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
>             Fix For: 1.8
> 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

View raw message