jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-7898) Facet queries with UNION should do trivial merge of facets from sub-queries
Date Fri, 23 Nov 2018 12:33:00 GMT

    [ 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

View raw message