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

["Julian Reschke (JIRA)" <ji...@apache.org>]

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

Julian Reschke commented on OAK-7898:
-------------------------------------

While releasing 1.6.16, we noticed that `org.apache.jackrabbit.oak.query.facet.FacetResult` now has the same API version as the variant in 1.8.10, despite their APIs not being identical. This is because 1.6 uses the old JSR 305 annotations, while 1.8 uses JetBrains annotations (see https://issues.apache.org/jira/browse/OAK-7511). We believe this is ok, and any "proper" fix (like backporting the annotation change to 1.6 as well) would be very complex.



> 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)