[ 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 bq. ...Should we have a syntax to apply stats/queries/ranges only at specific levels in the pivot hierarchy?... I spun this off into it's own issue: SOLR-6663 For now, i think we should focus on requiring example one tag value in the "stats" local param -- i incorporated that into some of the code/tests as i was reviewing... {panel:title=changes since last patch} * PivotFacetProcessor ** brought back getSubsetSize - it gives us a nice optimization in the cases where the actual subset isn't needed. ** getStatsFields *** renamed getTaggedStatsFields so it's a little more clear it's a subset relative this pivot *** made static so it's use of localparams wasn't soo obtuse (i hate how much "stateful" variables there are in SimpleFacets) *** added error throwing if/when user specifies multiple tags seperated by commas since we want to reserve for now and may use it for controlling where in the pivot tree stats are computed (SOLR-6663) *** javadocs ** doPivots *** refactored the new stats logic to all be in one place, and not to do anything (or allocate any extra objects) unless there are docs to compute stats over, and stats to compute for those docs * SolrExampleTests ** merged testPivotFacetsStatsParsed into testPivotFacetsStats *** testPivotFacetsStats didn't need any distinct setup from what testPivotFacetsStatsParsed, so i just moved the querys/assertions done by testPivotFacetsStats into testPivotFacetsStatsParsed and simplified the name *** removed the SOLR-6349 style local params from the stats.fields -- not supported yet, and if/when it is this test asserts that more stats are there then what those params were asking for, so we don't want it to suddenly break in the future. *** enhance the test a bit to sanity check these assertions still pass even when extra levels of pivots are requested. ** merge testPivotFacetsStatsNotSupportedBoolean + testPivotFacetsStatsNotSupportedString => testPivotFacetsStatsNotSupported *** "String" was not accurate, TextField is more specific *** also simplified the setup - no need for so many docs, and no need for it to be diff between the two diff checks *** added ignoreException -- the junit logs shouldn't misslead the user when an exception is expected *** added some additional assertions about the error messages *** added another assertion if multiple tags seperated by commas (SOLR-6663) * TestCloudPivots ** replaced nocommit comment with a comment refering to SOLR-6663 {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 > > > 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