Details
Description
Queries such as
//*[@name = 'Node1' or @text = 't2']/(rep:facet(text))
get split into 2 sub-queries such as
//*[@name = 'Node1']/(rep:facet(text))
//*[@test = 't2']/(rep:facet(text))
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.