[
https://issues.apache.org/jira/browse/OAK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-7898:
-------------------------------
Description:
Queries such as {noformat} //*[@name = 'Node1' or @text =
't2']/(rep:facet(text)) {noformat} get split into 2 sub-queries such as
# {noformat} //*[@name = 'Node1']/(rep:facet(text)) {noformat}
# {noformat} //*[@test = 't2']/(rep:facet(text)) {noformat}
Trivially merging facets (union of labels and sum of counts for same labels)
across sub-queries in generally wrong because of potential intersection rows.
But, in common practical cases, intersections aren't a big majority so, albeit
incorrect, trivial merge shouldn't be off huge amount. Note that usual path
restrictions and node type restrictions are the most common case with {{OR}}
and they do have have no intersection in almost all cases.
Also, while we'd re-sort the merged facets but we'd make no attempt to prune
the list to match limits on facet count implied by index-definitions. This is
basically for 2 reasons:
* sub-queries might get answered by separate indexes (this could be the case
with search on different node types)
* merge of facets would happen in query engine and we won't want to route back
information about index-definition or its semantics from index provider to
query engine
That said, since it's going to give incorrect result by design, we need to very
explicit in our documentation.
was:
Queries such as {noformat} //*[@name = 'Node1' or @text =
't2']/(rep:facet(text)) {noformat} get split into 2 sub-queries such as
# {noformat} //*[@name = 'Node1']/(rep:facet(text)) {noformat}
# {noformat} //*[@test = 't2']/(rep:facet(text)) {noformat}
Trivially merging facets (union of labels and sum of counts for same labels)
across sub-queries in generally wrong because of potential intersection rows.
But, in common practical cases, intersections aren't a big majority so, albeit
incorrect, trivial merge shouldn't be off huge amount. Note that usual path
restrictions and node type restrictions are the most common case with {{OR}}
and they do have have no intersection in almost all cases.
That said, since it's going to give incorrect result by design, we need to very
explicit in our documentation.
> Facet queries with UNION should do trivial merge of facets from sub-queries
> ---------------------------------------------------------------------------
>
> Key: OAK-7898
> URL: https://issues.apache.org/jira/browse/OAK-7898
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: lucene
> Reporter: Vikas Saurabh
> Assignee: Vikas Saurabh
> Priority: Major
>
> Queries such as {noformat} //*[@name = 'Node1' or @text =
> 't2']/(rep:facet(text)) {noformat} get split into 2 sub-queries such as
> # {noformat} //*[@name = 'Node1']/(rep:facet(text)) {noformat}
> # {noformat} //*[@test = 't2']/(rep:facet(text)) {noformat}
> Trivially merging facets (union of labels and sum of counts for same labels)
> across sub-queries in generally wrong because of potential intersection rows.
> But, in common practical cases, intersections aren't a big majority so,
> albeit incorrect, trivial merge shouldn't be off huge amount. Note that usual
> path restrictions and node type restrictions are the most common case with
> {{OR}} and they do have have no intersection in almost all cases.
> Also, while we'd re-sort the merged facets but we'd make no attempt to prune
> the list to match limits on facet count implied by index-definitions. This is
> basically for 2 reasons:
> * sub-queries might get answered by separate indexes (this could be the case
> with search on different node types)
> * merge of facets would happen in query engine and we won't want to route
> back information about index-definition or its semantics from index provider
> to query engine
> That said, since it's going to give incorrect result by design, we need to
> very explicit in our documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
