You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2015/05/12 13:01:00 UTC

[jira] [Created] (OAK-2863) No matching result found with use of relative property names in fulltext search in some cases

Chetan Mehrotra created OAK-2863:
------------------------------------

             Summary: No matching result found with use of relative property names in fulltext search in some cases
                 Key: OAK-2863
                 URL: https://issues.apache.org/jira/browse/OAK-2863
             Project: Jackrabbit Oak
          Issue Type: Bug
          Components: lucene
            Reporter: Chetan Mehrotra
            Assignee: Chetan Mehrotra
             Fix For: 1.3.0, 1.0.15


LucenePropertyIndex has support for transforming path when relative property names are used in fulltext search. Consider a case like below

{noformat}
+a1/doNotInclude/@propa=foo
+a2/doNotInclude/@propa=foo
...
+b/jcr:content/@propa=foo
{noformat}

And a query like
bq. /jcr:root//element(*, nt:base)[jcr:contains(jcr:content, 'foo' )]

Here the query uses a relative node name in contains {{jcr:content}} and only valid result is /b. Internally the query performed does not have any node name constraint and result in all path. Then while iterating the cursor would transform the path and see if path end with required name or not. If thats not the case then that result is ignored.

This logic works fine for normal cases. But if it so happens that first 50 results (default batch size) got ignored due to name mismatch then cursor would terminate early without looking further for valid result and hence end result appears that no matching results are found



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)