[jira] [Comment Edited] (OAK-7898) Facet queries with UNION should do trivial merge of facets from sub-queries

["Vikas Saurabh (JIRA)" <ji...@apache.org>]

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

Vikas Saurabh edited comment on OAK-7898 at 11/23/18 12:32 PM:
---------------------------------------------------------------

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


was (Author: catholicon):
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, 1.6.16
>
>
> 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)