[ 
https://issues.apache.org/jira/browse/OAK-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696691#comment-16696691
 ] 

Vikas Saurabh commented on OAK-7898:
------------------------------------

Backported to 1.8 at [r1847231|https://svn.apache.org/r1847231].

> 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
>             Fix For: 1.10, 1.8.10, 1.9.12
>
>
> 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)

Reply via email to