jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-7898) Facet queries with UNION should do trivial merge of facets from sub-queries
Date Tue, 08 Jan 2019 15:40:00 GMT

    [ 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

View raw message