[ https://issues.apache.org/jira/browse/OAK-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139072#comment-15139072 ]
Davide Giannella commented on OAK-3991: --------------------------------------- [~tmueller] {quote} but it should be converted to a union query without "or", so that the (Lucene) fullindex can be used. When the "or" condition is still there in the subquery, the fulltext index can't be used {quote} but this is the exactly the same case that OAK-1617 addressed for standard queries. Not union. Would it make sense to apply the same logic then a UnionQueryImpl? Asking therefore to find alternatives at the lowest layer (ast)? The only setback I can see here is that if we then have to backport it, we should have to backport OAK-1617 as well which was quite a change on the query engine level providing even new API. Or would it make sense to see if leveraging OAK-1617 on trunk and another approach on 1.2? > Incorrect resultset from XPATH, multiple ORs and Lucene full-text > ----------------------------------------------------------------- > > Key: OAK-3991 > URL: https://issues.apache.org/jira/browse/OAK-3991 > Project: Jackrabbit Oak > Issue Type: Bug > Components: lucene, query > Affects Versions: 1.2.10, 1.3.15 > Reporter: Davide Giannella > Assignee: Thomas Mueller > Priority: Blocker > Fix For: 1.4, 1.3.16 > > Attachments: OAK-3991-test.patch > > > In case of more complex xpath queries with a mix of ORs, ANDs and > full-text the returned resultset is wrong. Some of the conditions are > lost during the query execution. Most probably during the Filter > creation. > The query is: > {noformat} > /jcr:root/test//element(*, nt:unstructured)[ > ( > jcr:contains(., 'cinema') > or @tags = 'architecture-keywords:building/cinema' > or @tags = '/tags/architecture-keywords/building/cinema' > ) > and @status = 'amber' > and ( > not(@id) > and ( not(@types) > or ( > not(@types = 'published') > and not(@types = 'page') > and not(@types = 'asset') > ) > ) > )] > {noformat} > In this case if you replace the @tags conditions with a > {{jcr:contains}} rather than {{=}} it will make the query works. Which > suggests the same root cause of OAK-2660. > OAK-2660 was indirectly addressed by OAK-1617 but the OR->UNION > conversion is not applied to subqueries of a UNION set. > See [attached patch|^OAK-3991-test.patch] for a reproducing test case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)