[
https://issues.apache.org/jira/browse/SOLR-6351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-6351:
---------------------------
Attachment: SOLR-6351.patch
review & some updates to the the latest tests Vitaliy added.
On monday i'll dig into how we're dealing with stas in pivot refinements (the
last remaining "nocommit" ... i can't understand how/why
DistributedFacetPivotSmallAdvancedTest.doTestTopStatsWithRefinement passes in
this patch, and that scares me (the refinement call should pollute the top
level stats, double counting at least one shard) so i really want to get to the
bottom of it.
{panel:title=patch changes}
* FacetPivotSmallTest
** new testBogusStatsTag: check that a bogus stats tag is ignored
** new testStatsTagHasComma: check that comma causes error for now (SOLR-6663)
* SolrExampleTests
** swap two comments that were on the wrong asserts
* DistributedFacetPivotSmallAdvancedTest
** cleaned up some formatting
** doTestTopStats
*** beefed up the assertions
*** added sanity checks that refinement really was happening in these requests
*** suprisingly this test still passes ... based on the "nocommit" hack i put
in StatsComponent, I was farily certain this was going to fail ... i need to
dig in more and make sure i understand why it doesn't fail.
*** renamed to doTestTopStatsWithRefinement to make it a bit more clear what
it's doing
** doTestDeepPivotStatsOnOverrequest
*** removed this test - i wasn't really clear on the purpose, and in asking
Vitaliy about it on IRC we realized he had missunderstood some advice i'd given
him on IRC a few days ago about how to "sanity check" that refinement was
happening (ie: what i just added to doTestTopStatsWithRefinement) so it wasn't
given us any value add.
{panel}
> Let Stats Hang off of Pivots (via 'tag')
> ----------------------------------------
>
> Key: SOLR-6351
> URL: https://issues.apache.org/jira/browse/SOLR-6351
> Project: Solr
> Issue Type: Sub-task
> Reporter: Hoss Man
> Attachments: SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch, SOLR-6351.patch,
> SOLR-6351.patch
>
>
> he goal here is basically flip the notion of "stats.facet" on it's head, so
> that instead of asking the stats component to also do some faceting
> (something that's never worked well with the variety of field types and has
> never worked in distributed mode) we instead ask the PivotFacet code to
> compute some stats X for each leaf in a pivot. We'll do this with the
> existing {{stats.field}} params, but we'll leverage the {{tag}} local param
> of the {{stats.field}} instances to be able to associate which stats we want
> hanging off of which {{facet.pivot}}
> Example...
> {noformat}
> facet.pivot={!stats=s1}category,manufacturer
> stats.field={!key=avg_price tag=s1 mean=true}price
> stats.field={!tag=s1 min=true max=true}user_rating
> {noformat}
> ...with the request above, in addition to computing the min/max user_rating
> and mean price (labeled "avg_price") over the entire result set, the
> PivotFacet component will also include those stats for every node of the tree
> it builds up when generating a pivot of the fields "category,manufacturer"
--
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
