[
https://issues.apache.org/jira/browse/LUCENE-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649661#comment-13649661
]
Michael McCandless commented on LUCENE-4980:
--------------------------------------------
bq. What if RangeAccumulator did that under the covers?
Well ... I have a TODO to also support SortedSetDocValuesAccumulator. So I'm
not quite sure what to name it / where to put it.
Another option here is to commit this class only under src/test ... it's
technically only needed right now by the test case to expose the bugs ... but
then I'm using the class in the Jira search app, because I need to use
DrillSideways with range and non-range facets, and without it things get very
messy. So we need to fix something here, but we can do it in a separate issue
after fixing these bugs.
bq. Minor comments about the class: (a) can you rename 'a' and 'ra'?
Will do ...
bq. (b) why do you need to hold onto fspOrig? Is it because FA.searchParams
isn't final?
I need fspOrig in accumulator() to un-collate the wrapped List<FacetResult>
back in the same order as the original requests ...
> Can't use DrillSideways with both RangeFacetRequest and non-RangeFacetRequest
> -----------------------------------------------------------------------------
>
> Key: LUCENE-4980
> URL: https://issues.apache.org/jira/browse/LUCENE-4980
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/facet
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4980.patch
>
>
> I tried to combine these two and there were several issues:
> * It's ... really tricky to manage the two different
> FacetAccumulators across that N FacetCollectors that DrillSideways
> creates ... to fix this I added a new MultiFacetsAccumulator that
> switches for you.
> * There was still one place in DS/DDQ that wasn't properly handling
> a non-Term drill-down.
> * There was a bug in the "collector method" for DrillSideways
> whereby if a given segment had no hits, it was skipped, which is
> incorrect because it must still be visited to tally up the
> sideways counts.
> * Separately I noticed that DrillSideways was doing too much work:
> it would count up drill-down counts *and* drill-sideways counts
> against the same dim (but then discard the drill-down counts in
> the end).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
