[
https://issues.apache.org/jira/browse/OAK-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040323#comment-18040323
]
Thomas Mueller commented on OAK-12007:
--------------------------------------
It looks like there is an (independent) bug with the conversion to "union" in
SQL-2, for "contains" clauses:
{noformat}
select * from [nt:base] as a where contains([child/b], 'b') or [child/c]=3
=>
select [a].[jcr:primaryType] as [a.jcr:primaryType] from [nt:base] as [a] where
[a].[child/c] = 3
union
select [a].[jcr:primaryType] as [a.jcr:primaryType] from [nt:base] as [a] where
contains([a].[b], 'b')
{noformat}
The "child" is lost in the last contains part (at the very end). It should be:
{noformat}
select [a].[jcr:primaryType] as [a.jcr:primaryType] from [nt:base] as [a] where
contains([a].[child/b], 'b')
{noformat}
> XPath with "or" conditions should not always be converted to "union"
> --------------------------------------------------------------------
>
> Key: OAK-12007
> URL: https://issues.apache.org/jira/browse/OAK-12007
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Reporter: Thomas Mueller
> Priority: Major
>
> In OAK-1432, XPath queries with "or" conditions are always converted to
> "union" queries.
> There are some queries that do not benefit from this forced conversion to
> "union", for example queries that use elasticsearch indexes for both parts,
> but where one of the properties is not indexed. In general, it would be
> better to compare the cost of the union with the cost of the non-union query,
> and then pick the one with the lower cost.
> In fact, for SQL-2 queries with "or" conditions, that is how it's working
> since OAK-1617.
> It's a bit dangerous now (after such a long time) to always disable the
> forced "union" conversion for XPath queries. But, what we could do is disable
> the forced conversion using a feature toggle.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
