[
https://issues.apache.org/jira/browse/OAK-12007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18040343#comment-18040343
]
Thomas Mueller commented on OAK-12007:
--------------------------------------
So LuceneIndexAggregation2Test I can fix.
The ResultSizeTest, WhiteboardResultSizeTest, and LucenePropertyIndexTest are
expected (assertion needs to be changed). That leaves 3 facet test failures
that don't have an explanation so far:
{noformat}
[ERROR]
FacetTest>AbstractJCRTest.run:476->testDistinctUnionWithDifferentFacetsOnSubQueries:814
expected:<2> but was:<0>
[ERROR]
FacetTest>AbstractJCRTest.run:476->testMergedFacetsOverUnionSummingCount:916
Unexpected dimensions expected:<[text]> but was:<[]>
[ERROR]
FacetTest>AbstractJCRTest.run:476->testMergedFacetsOverUnionUniqueLabels:841
Unexpected dimensions expected:<[text]> but was:<[]>
{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)
