[
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
