[
https://issues.apache.org/jira/browse/SOLR-6193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14059391#comment-14059391
]
Hoss Man commented on SOLR-6193:
--------------------------------
The crux of the problem is that the distributed facet logic, and the the shard
sub-requests are generated, pre-dates the support for using local params in
{{facet.field}} and is built upon the previous work of using "per-field"
overrides (ie: {{f.myFieldName.facet.mincount=5}}).
As a result, from my quick review of the code, there seem to be 2 different
types of mistakes that can pop up in logic for building the shard requests:
* not recognizing at the local params when computing shard request values (ie:
ignoring localparam facet.limit to decide what the overrequest values should be
for a given field)
* propogating the localparam values to the shards in addition to the
syntheticly generated f.foo.param equivilent for the shard (ie: sending the
original localparams which might include facet.mincount even when the
distributed logic is trying to force a mincount of 0 for the initial "top-N"
computation.
Adding to the complications, is that off the top of my head, i can't remember
what sort of decisions were made when the localparam support was added
regarding the precidence between a general local param vs a top level per-field
param -- ie: what should the effective limit be here:
{{f.foo.facet.limit=99&facet.field=\{!facet.limit=44\}foo}}
---
I think in general we should overhaul the way the distributed requests modify
the per-field facet params to instead put all of those per field modifications
directly in the local params of the shard requests -- among other things, this
will help eliminate collision in some of the computed facet params when
faceting on the same field multiple ways.
before we tackle this though, we need a lot more comprehensive tests for some
of these more complex situations -- beyond just the minimal distrib test that
compares with the control collection. We need to assert that we get the
specific expect responses, otherwise we could break both the existing
single-node behavior in a lot of cases and never notice as long as the distrib
behavior breaks in the same way.
> using facet.* parameters as local params inside of facet.field causes
> problems in distributed search
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-6193
> URL: https://issues.apache.org/jira/browse/SOLR-6193
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 4.8.1
> Environment: OS X 10.9.3 Apache Tomcat 7.0.41
> Debian Apache Tomcat 7
> Reporter: John Gibson
> Attachments: bad_facet_offset_test_4_8_x.patch
>
>
> The distributed request logic for faceting (which has to clone&modify
> requests to individual shards for dealing with things like facet.mincount,
> facet.sort, facet.limit, & facet.offset so that the distributed aggregation
> is correct) doesn't properly take into account localparams contained in each
> of the facet params and how they should affect the initial shard requests and
> the subsequent refinement requests.
> {panel:title=Initial problem example reported by user}
> When a distributed search contains multiselect faceting the per-field
> faceting options are not honored for alternate selections of the field. For
> example with a query like:
> {noformat}
> facet.field=blah&facet.field={!key myblah
> facet.offset=10}blah&f.blah.facet.offset=20
> {noformat}
> The returned facet results for both blah and myblah will use an offset of 20
> as opposed to a standard search returning myblah with an offset of 10.
> {panel}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
