[
https://issues.apache.org/jira/browse/OAK-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16825958#comment-16825958
]
Vikas Saurabh commented on OAK-8271:
------------------------------------
Attaching [^OAK-8271.patch] which takes the mentioned approach for
non-fulltext conditions while retains the earlier approach for fulltext
conditions. It required to tweak an earlier test for property restriction
accordingly.
[~tmueller], as you expected, {{//}} type condition doesn't work but other
conditions that are utilizing wildcard do work out. I'm not sure where should
we document this though (I don't think we want to "support" {{//}} necessarily).
> Lucene path transformed result doesn't accomodate wildcards in relative path
> ----------------------------------------------------------------------------
>
> Key: OAK-8271
> URL: https://issues.apache.org/jira/browse/OAK-8271
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: lucene
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Minor
> Attachments: OAK-8271.patch
>
>
> {{LucenePropertyIndex}} support answering a query with property constraint on
> a relative path if there's an property (non-relative) is indexed on
> {{nt:base}}.
> e.g. with an index def such as
> {noformat}
> + /oak:index/fooIndex/indexRules/nt:base/properties
> + foo
> - propertyIndex=true
> {noformat}
> we can answer queries such as
> {noformat}
> /jcr:root/a//element(*, some:type)[b/foo='bar']
> /jcr:root/a//element(*, some:type)[b/c/foo='bar']
> {noformat}
> In the same spirit it could also support query with wildcard in relative path
> fragment
> {noformat}
> /jcr:root/a//element(*, some:type)[b/*/foo='bar']
> {noformat}
> .... but it doesn't work currently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
