[
https://issues.apache.org/jira/browse/SOLR-14467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17116880#comment-17116880
]
Chris M. Hostetter commented on SOLR-14467:
-------------------------------------------
bq. One general question: when SlotContext.isAllBucket()==true, what would be
returned by SlotContext.getSlotQuery()?
I would suggest that the javadoc for {{getQuery()}} should say that it's
behavior is undefined if {{isAllBucket()}} is true -- from an implementation
standpoint i think throwing {{IllegalStateException}} is is going to be the
best/fastest way to catch bugs.
bq. FWIW I thought a little more about why I proceeded under the assumption
that relatedness() would be meaningful for allBuckets. I actually do think it
could be relevant, but in a way that (upon further reflection) I think can only
be practically calculated using sweep collection. ...
Let's file a new "Improvement" jira to re-consider this topic down the road,
cross link back to this issue for the existing context/discussion of semantic
meaning & implementation ideas, and make sure that the changes we make to
SlotAcc & SKGAcc for this bug fix have 'TODO' comments linking to the new issue
as possible improvements.
bq. Oh, and in light of this conversation, I'm guessing we should probably
force-push/overwrite all of my most recent ...
Well, that's entirely up to you -- it's your repo, and doesn't affect me much
(both because i odn't have any significant unpushed changes, and because i'm
always very cautions about preserving work in patch files and stashes).
If you're asking my opinion: I personally think force-push is the single
greatest failure in the design of GIT, and if i was in charge at github I would
completely disable it for all repos and tell people who want to use it to find
hosting elsewhere ... it's the antithesis of collab development (even if
there's only one person with rights to "push" it can cause problems for anyone
who has the ability to "fetch" and depends on the repo).
If your motivation is to try and keep the history on the PR branch clean, don't
worry about it -- i'm not sure how PR normally get "applied" if you use the
gitub UI, but i'll ultimately do it manually either via squash merge or by
actually generating a new patch file (I mentioned before: I'm old school)
> 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.patch, 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
