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] [Created] (OAK-6628) More precise indexRules support via filtering criteria on property
Date Thu, 07 Sep 2017 06:14:00 GMT
Chetan Mehrotra created OAK-6628:

             Summary: 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

  - 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"

So indexRule would have 2 more config properties
* filter-property - Name of property to match
* filter-value - The value to match


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


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