[ 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