[
https://issues.apache.org/jira/browse/OAK-3991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15139013#comment-15139013
]
Thomas Mueller commented on OAK-3991:
-------------------------------------
Yes, semantically, the conversion is correct, 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. Same for
{noformat}
/jcr:root//*[(@a=1 or @b=1) and (@c=2 or (@c=3 and @c=4))]
select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 2
and isdescendantnode(a, '/')
and [a] = 1
union select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 2
and isdescendantnode(a, '/')
and [b] = 1
union select [jcr:path], [jcr:score], *
from [nt:base] as a
where isdescendantnode(a, '/')
and ([a] = 1
or [b] = 1)
and [c] = 3
and [c] = 4
{noformat}
This is without "contains" (without fulltext index). There should be no "or",
instead 4 union subqueries should be used. What is strange is that by removing
the path constraint, the conversion is correct:
{noformat}
//*[(@a=1 or @b=1) and (@c=2 or (@c=3 and @c=4))]
select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 2
and [a] = 1
union select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 2
and [b] = 1
union select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 3
and [c] = 4
and [a] = 1
union select [jcr:path], [jcr:score], *
from [nt:base] as a
where [c] = 3
and [c] = 4
and [b] = 1
{noformat}
Please note that c can be both 3 and 4 at the same time, when using
multi-valued properties.
> 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)
