[
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
quick question for [~vzhovtiuk]: in an earlier comment, you mentioned creating
a new "FacetPivotSmallTest.java" test based on my earlier outline of how to
move forward -- but in later patches that test wasn't included. was there a
reason for removing it ? or was that just an oversight when generating the
later patches? Can we resurect that test from some of your earlier patches?
----
Been focusing on TestCloudPivotFacet. One particularly larg change to note...
After doing a bit of refactoring of some stuff i've mentioned in previous
comments, i realized that buildRandomPivotStatsFields & buildStatsTagString
didn't really make a lot of sense -- notably due to some leftover cut/paste
comment cruft. digging in a bit, i realized that the way buildStatsTagString
was being called, we were only ever using the first stats tag w/ the first
facet.pivot -- and obliterating the second pivot from the params if there was
one.
So i ripped those methods out, and re-vamped the way the random stats.field
params were generated, and how the tags were associated with the pivots using
some slightly diff helper methods.
{panel:title=changes since last patch}
* TestCloudPivotFacet
** moved stats & stats.field params from pivotP to baseP
*** this simplified a lot of request logic in assertPivotStats
** buildRandomPivotStatsFields & buildStatsTagString
*** replaced with simpler logic via pickRandomStatsFields & buildPivotParamValue
**** this uncovered an NPE in StatsInfo.getStatsFieldsByTag (see below)
*** fixed pickRandomStatsFields to include strings (not sure why they were
excluded - string stats work fine in StatsComponent)
** assertPivotStats
*** switched from one verification query per stat field, to a single
verification query that loops over each stats
*** shortened some variable names & simplified assert msgs
*** added some hack-ish sanity checks on which stats were found for each pivot
** assertPivotData
*** wrapped up both assertNumFound & assertPivotStats so that a single query is
executed and then each of those methods validates the data in the response that
they care about
** added "assertDoubles()" and "sanityCheckAssertDoubles()"
*** hammering on the test lead to a situation where stddev's were off due to
double rounding because of the order that the sumOfQuares were accumulated from
each shared (expected:<2.3005390038169265E9> but was:<2.300539003816927E9>)
*** so i added a helper method to compare these types of stats with a "small"
epsilon relative to the size of the expected value, and a simple sanity checker
to test-the-test.
* QueryResponse
** refactored & tightened up the pivot case statement a bit to assert on
unexpected keys or value types
* StatsComponent
** fixed NPE in StatsInfo.getStatsFieldsByTag - if someone asks for
"{{facet.pivot=\{!stats=bogus\}foo}}" (where 'bogus' is not a valid tag on a
stats.field) that was causing an NPE - should be ignored just like ex=bogus
{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
>
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
