jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davide Giannella (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (OAK-6628) More precise indexRules support via filtering criteria on property
Date Tue, 04 Jun 2019 15:38:12 GMT

     [ 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.14.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.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)

Mime
View raw message