lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-7116) Facet refinement shard request should disable other faceting types
Date Tue, 17 Feb 2015 23:54:12 GMT

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

Hoss Man commented on SOLR-7116:
--------------------------------

skimming the patch looks ok to me ... one point to clarify...

bq. ... 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. ...

that's not entirely true.  The point behind a lot of the shard request logic is to try and
_share_ requests to the shards whenever possible.  just like we piggy back facet facet refinement
on PURPOSE_GET_FIELDS if we can find one, we also try to combine facet.field refinement with
facet.pivot refinement if both are in use.

so for example, if you have a request with {{facet.field=XX&facet.pivot=YY,ZZ}} then you
should see one request each shard with both facet.field=XX and facet.pivot=YY refinements
requested at the same time -- then once YY has been refined, a second request to every shard
with facet.pivot=YY,ZZ refinements. (ie: only 2 total refinement request to each shard, not
3)

I _think_ from looking at your patch, this should still be true? did you try this in your
manual tests?

bq. I guess I could add a proper test for this by examining debug=track.

I've thought about trying to do whitebox tests to verify that a single cloud request triggers
the expected shard requests, but i could never figure out a decent idea for how to do it w/o
a lot of complex "mocking" up of solr ... if you've got an idea in mind, please open an issue
with your thoughts.


> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message