[ 
https://issues.apache.org/jira/browse/SOLR-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

David Smiley updated SOLR-7116:
-------------------------------
    Attachment: SOLR-7116__facet_refinement_opt.patch

The attached patch fixes the problem.  When a refinement request is being 
created for facet.field or facet.pivot, it removes the main facet types first 
now with a little utility method, before subsequently adding the parameters it 
needs.  I also saw that in the event there is a need to do a facet.pivot 
refinement but not a facet.field refinement, it seems to create and add a new 
shard request for facet.field _anyway_ (with essentially no search options), so 
I fixed that.

To observe the problem, I _locally_ hacked TestDistributedSearch and added 
{{debug=track}} to observe what happens when I combine a facet.field request 
that needs refinement with range faceting. And indeed the refinement request 
did the range faceting pointlessly.  I guess I *could* add a proper test for 
this by examining debug=track.

As an aside, I can't help but feel FacetComponent needs a re-architecture, 
along with its tests such that these things can be combined without the code 
for each being intertwined, and to enable random testing of different types of 
faceting together instead of testing these purely in isolation.

[~hossman_luc...@fucit.org] would you mind looking at the patch?  It's small.

> Facet refinement shard request should disable other faceting types
> ------------------------------------------------------------------
>
>                 Key: SOLR-7116
>                 URL: https://issues.apache.org/jira/browse/SOLR-7116
>             Project: Solr
>          Issue Type: Improvement
>          Components: faceting
>            Reporter: David Smiley
>            Assignee: David Smiley
>             Fix For: 5.1
>
>         Attachments: SOLR-7116__facet_refinement_opt.patch
>
>
> While examining FacetComponent in the process of adding the new facet.heatmap 
> faceting type, I observed that distributed shard refinement requests were 
> built by copying the existing parameters and then modifying ones pertinent to 
> facet.field or facet.pivot depending on the type of refinement requests 
> (which in turn only happens some of the time, not too often).  Those are the 
> only types of faceting that have a refinement phase.  These refinement 
> requests _should not_ have facet.query, facet.date, facet.range, 
> facet.interval, or facet.heatpmap since they don't participate in 
> refinement... and furthermore, facet.field and facet.pivot have their own 
> dedicated refinement requests and so a facet.field request _should not_ have 
> options for facet.pivot.  But this isn't taken care of, just facet.query is 
> removed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to