[
https://issues.apache.org/jira/browse/LUCENE-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13721944#comment-13721944
]
Shai Erera commented on LUCENE-4985:
------------------------------------
I discussed this with Gilad and perhaps the situation today is not that bad,
and we can do away with few minor changes. Today one can already construct a
FacetsAccumulator given the FacetRequests that he wishes to execute.
RangeAccumulatorWrapper attempts to allow you to work with RangeAccumulator and
FacetsAccumulator (and it has a TODO to work for SortedSet too). So maybe what
we need is the following simple solution:
* Make FacetsAccumulator abstract, as outlined above, with implementations for
Taxonomy, Range, SortedSet and Multi.
* Each of the accumulator impls take the needed parameters in the ctor:
** List<FacetRequest> -- the requests that are relevant to *this* accumulator
only.
** SortedSetReaderState for SortedSetDVAccumulator,
TaxoReader/FacetIndexingParams etc. for TaxonomyFacetAccumulator.
* If you want to combine different requests, you construct the relevant
accumulators and wrap w/ MultiFacetsAccumulator.
* Two choices w.r.t. taxonomy accumulators:
** Keep them as FacetsAggregator - don't change much code, but keeps some
aggregators with irrelevant API, such as rollupValues which is not implemented
by the associations aggregators (only relevant for hierarchical facets and
counting)
** Convert all of them to TaxonomyFacetsAccumulator which implement some
abstract method, so that TaxoFA drives the accumulation and implements the
common logic of computing top-k over FacetArrays and labeling. This changes
existing aggregators ...
Bottom line is, a FacetRequest documents which accumulator should be used, but
does not declare a createAccumulator() method, which leads to all the issues
I've described above. Its matching accumulator will also make sure that the
list of requests passed to it are "OK" (much like is done today).
This has another advantage of keeping e.g. CountFacetRequest as-is, and support
it by both a CountingTaxonomyFacetsAccumulator and SortedSetFacetsAccumulator.
I'll start with this route and see where it leads me.
> Make it easier to mix different kinds of FacetRequests
> ------------------------------------------------------
>
> Key: LUCENE-4985
> URL: https://issues.apache.org/jira/browse/LUCENE-4985
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Michael McCandless
> Fix For: 5.0, 4.5
>
>
> Spinoff from LUCENE-4980, where we added a strange class called
> RangeFacetsAccumulatorWrapper, which takes an incoming FSP, splits out the
> FacetRequests into range and non-range, delegates to two accumulators for
> each set, and then zips the results back together in order.
> Somehow we should generalize this class and make it work with
> SortedSetDocValuesAccumulator as well.
--
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]
