[
https://issues.apache.org/jira/browse/OAK-4906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15564980#comment-15564980
]
Julian Sedding commented on OAK-4906:
-------------------------------------
IMHO it would make sense to add:
3b. If {{indexNodeName=true}} add constraint for {{NAME() = 'jcr:content'}}
WDYT?
> Support relative property based query by transforming the path
> --------------------------------------------------------------
>
> Key: OAK-4906
> URL: https://issues.apache.org/jira/browse/OAK-4906
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Fix For: 1.6
>
>
> PropertyIndex supports query like below
> {noformat}
> /jcr:root//*[jcr:content/@keywords]
> {noformat}
> For such query _keywords_ property is indexed and the as part of Cursor
> returned for the query the path is transformed to return the parent path if
> the parent node is _jcr:content_
> Currently LucenePropertyIndex supports indexing relative properties wrt base
> node like {{jcr:content/metadata/status}}. Here it would index the relative
> property by refererring to its relative name.
> To simplify switch to LucenePropertyIndex (as part of hybrid index support)
> LucenePropertyIndex should also support for such queries where property index
> definition only specifies indexing _keywords_ but the query is using a
> relative property. So LucenePropertyIndex should
> # First check if it has a property definition for _jcr:content/keywords_
> # If not check if the indexingRule is for nt:base
> # If yes check if it has property definition for _keywords_
> # If yes then use the index to evaluate the query and return transformed
> result
> LucenePropertyIndex already do such transformations for fulltext constraints.
> With this we extend that support for property restrictions also
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
