[
https://issues.apache.org/jira/browse/SOLR-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17107525#comment-17107525
]
Chris M. Hostetter commented on SOLR-14467:
-------------------------------------------
{quote}I noticed that the test patch attached here only removes the
TestCloudJSONFacetSKG.java file from master, and doesn't add any tests?
{quote}
Hmm, yeah - not sure how i botched that .. IIRC my "trivial patch to
TestCloudJSONFacetSKG" to demonstrate the various errors was simply adding a
hardcoded {{allBuckets:true,}} to the JSON output string in the {{TermFacet}}
class.
{quote}My initial intuition is that having stats for allBuckets represent the
union across all buckets (whether returned or not)
{quote}
That is hte only interpretation i have ever had/imagined for how allBuckets is
ment to work, and jives with how it behaves for count and "simple" stats...
{noformat}
$ bin/solr -e techproducts
...
$ curl http://localhost:8983/solr/techproducts/query -d
'q=*:*&rows=0&omitHeader=true&json.facet=
{
"categories": {
"type": "terms",
"field": "cat",
"limit": 1,
allBuckets: true,
facet : { sum : "sum(price)" }
}
}'
{
"response":{"numFound":32,"start":0,"numFoundExact":true,"docs":[]
},
"facets":{
"count":32,
"categories":{
"allBuckets":{
"count":37,
"sum":8563.560066223145},
"buckets":[{
"val":"electronics",
"count":12,
"sum":2772.3200187683105}]}}}
{noformat}
{quote}...but I think that would mean preventing any deferral of stats when
allBuckets==true, which is not currently done. But I think that approach (if
chosen) would be pretty straightforward: if allBuckets==true, instead of
creating any otherAccs, simply add all accs to collectAcc using MultiAcc?
{quote}
Hmmmm.... I'm really not sure either way – but IIUC the whole point of
SpecialSlotAcc is that it *does/can* do collection against all of the
{{otherAccs}} using the {{otherAccsSlot}}.
I suspsect the key bug here is just in how the {{slotContext}} works when
dealing with these "special" slots ... SpecialSlotAcc may just need to ensure
it passes down it's own slot context that ignores the slot# it get's passed and
instead wraps/hides usage of
SpecialSlotAcc.otherAccsSlot/SpecialSlotAcc.collectAccSlot as needed? (which i
gather may be along the lines of what you've recently tried adding in your
recent SOLR-13132 commits? ... haven't dug in there yet).
If that's really the underlying problem then it won't really matter if MultiAcc
is used everytime we have {{allBuckets:true}} situation, because we'll still
need that "slot mapping" logic for the special slot.
Ultimately though, I still don't have a good conceptual grasp of what the
"correct" {{relatedness()}} stats _should be_ for the {{allBuckets}} situation
– relatedness values are fundamentally about the "domain" of the entire bucket
realteive to the foreground/background sets, so doesn't really make sense to
try and "merge" the values from multiple buckets. Ultimately it may not matter
_what_ value we compute for {{relatedness()}} in an {{allBuckets:true}} bucket
(My gut says we should just using the {{base}} DocSet/domain for the entire
facet as the slotContext in SpecialSlotAcc, ... but i can imagine there might
be other interpretations) as long as we don't "fail" with an error if someone
tries.
> inconsistent server errors combining relatedness() with allBuckets:true
> -----------------------------------------------------------------------
>
> Key: SOLR-14467
> URL: https://issues.apache.org/jira/browse/SOLR-14467
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Facet Module
> Reporter: Chris M. Hostetter
> Priority: Major
> Attachments: SOLR-14467_test.patch
>
>
> While working on randomized testing for SOLR-13132 i discovered a variety of
> different ways that JSON Faceting's "allBuckets" option can fail when
> combined with the "relatedness()" function.
> I haven't found a trivial way to manual reproduce this, but i have been able
> to trigger the failures with a trivial patch to {{TestCloudJSONFacetSKG}}
> which i will attach.
> Based on the nature of the failures it looks like it may have something to do
> with multiple segments of different sizes, and or resizing the SlotAccs ?
> The relatedness() function doesn't have much (any?) existing tests in place
> that leverage "allBuckets" so this is probably a bug that has always existed
> -- it's possible it may be excessively cumbersome to fix and we might
> nee/wnat to just document that incompatibility and add some code to try and
> detect if the user combines these options and if so fail with a 400 error?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
