[
https://issues.apache.org/jira/browse/LUCENE-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13719637#comment-13719637
]
Shai Erera commented on LUCENE-4985:
------------------------------------
I have been thinking about how to achieve that .. here's a proposal:
* Make FacetsAccumulator abstract with following current impls:
** TaxonomyFacetsAccumulator, assumes that TaxoReader is needed, FacetArrays
etc.
** SortedSetFacetsAccumulator, assumes that categories were indexed to a
SortedSetDVField
** RangeFacetsAccumulator, for computing facet ranges on NumericDV
** MultiFacetsAccumulator allows chaining several ones (basically a generic
version of RangeFacetsAccumulatorWrapper)
* Add to FacetRequest.createFacetsAccumulator()
** CountFacetRequest, Association**FacetRequest return TaxoFacetsAccumulator
** SortedSetCountFacetRequest returns SortedSetFA (and also verify that the
given CategoryPath was actually indexed in a SortedSetDVField)
** RangeFacetRequest returns RangeFacetsAccumulator
This pretty much divides the FacetRequests into the "source" from which they
read the facets information. Now we need to handle the different aggregation
functions currently supported by the TaxoFacetAcc variants: counting,
associations. TaxoFacetAcc will let you specify the FacetsAggregator:
* CountFacetRequest will set the aggregator to FastCounting (if possible) or
just Counting.
* **AssociationFacetRequest will set the aggregator to the matching one
* Additional requests can set their own aggregator
* FacetsAggregator will need to implement equals() and hashCode()
Then we'll have FacetsAccumulator.create(List<FacetRequest>) which creates the
right accumulator:
* Group all requests that use the same FacetsAccumulator, so that all RangeFRs
are grouped together, all TaxoFacetAcc requests together etc.
* For the TaxoFacetAcc requests, it groups them by their aggregator, so that:
** All CountingAggregators that read the same category list are grouped
together, separate from ones that do counting yet on a different category list
** All AssociationAggregators are grouped together, by their function, list id
etc.
* It then creates either a single accumulator, or MultiFacetAccumulator which
chains the accumulate call
What do we gain -- it's easy for an app to create the right accumulator for a
given list of requests. Today it needs to sort of do this logic on its own,
which is sometimes impossible (e.g. if it's a component that doesn't know what
it's given). Also, the requests are self-descriptive.
What do we lose -- today if one wants to count A, B and C using
CachedOrdsCountingFacetsAggregator, it needs to override
FacetsAccumulator.getAggregator(), once. With this change, he will need to do
that for every CountFacetRequest he creates .. I think that's an OK tradeoff,
given the situation today which makes apps' life tougher.
I think we'll also need to create an Aggregator (old FacetsAggregator) wrapper.
It is still needed by StandardFacetsAccumulator, until we finish the cleanup of
sampling, complements counting etc. I'll look into that too, perhaps it can be
done separately in a different issue.
Now need to hope I took all the parameters into account, and won't hit a brick
wall when trying to implement it :).
> 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]
