[
https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13991118#comment-13991118
]
Hoss Man commented on SOLR-2894:
--------------------------------
bq. He said it's important that we don't use the variable number of shards in
this particular because it exercises a number of specific sharding situations
to ensure that we get the correct answers.
that makes complete sense -- i just wanted to make sure it's a _test_
requirement and not a _feature_ requirement. We should definitely comment the
test to that effect, and add a more randomized cloud based test with some
dynamic shard assignment as well to try and help catch strange edge cases.
I'll try to work on that to help me better understand the feature (in general,
it's been a long time since i looved at pivot faceting)
bq. I will spend some time on this on Thursday to see if I can clean this area
up and make it a little more straight forward.
that would be great, thanks. The Map vs Set aspect would be a trivial
improvement, but in general i'm more concerned about the odd flow -- it seems
like something that could easily bite us in the ass later when people try to
maintain it. It seems like it would be a lot more straight forward to:
* have modifyRequest unconditionally remove all limit/offset/overrequest params
from the shard requests
* have a simple "getOverrequestLimitAmount(String fieldName)" method in the
FacetInfo class (that consults the _original_ request params)
* have each code path (facet.field & facet.pivot & whatever down the road...)
that sets params on the shard request and cares about over requesting call
{{sreq.params.set(pre + FACET_LIMIT, getOverrequestLimitAmount(fieldName))}}
bq. Having two different purposes allows us to call refineFacets and/or
refinePivotFacets only as needed to avoid looping through the shard responses
an extra time. If your comment is more to the effect that the loop in
refineFacets() and refinePivotFacets() could be merged into a single loop...
I don't have an opinion, i just wanted to understand the purpose of the new
"PURPOSE" (heh) since we don't have a special one for range facets or query
facets -- but in hindsight i realize that of course we don't: those don't need
refinement.
> Implement distributed pivot faceting
> ------------------------------------
>
> Key: SOLR-2894
> URL: https://issues.apache.org/jira/browse/SOLR-2894
> Project: Solr
> Issue Type: Improvement
> Reporter: Erik Hatcher
> Fix For: 4.9, 5.0
>
> Attachments: SOLR-2894-reworked.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch,
> dateToObject.patch
>
>
> Following up on SOLR-792, pivot faceting currently only supports
> undistributed mode. Distributed pivot faceting needs to be implemented.
--
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
