[
https://issues.apache.org/jira/browse/LUCENE-4985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13722375#comment-13722375
]
Shai Erera commented on LUCENE-4985:
------------------------------------
Adding State to .create() does not simplify life for an app I think, because
someone (on the app side) will need to figure out if State should be null or
not. I'm worried that users will end up creating State even if they don't need
it?
And since MultiFacetAccumulator lets you wrap any accumulator yourself, I think
it's fine that these are separate methods, as a first step.
I'm worried about adding SortedSetDVFacetRequest, because unlike
Count/SumScore/SumIntAssociation, this request is solely about the underlying
source? And it also implies only counting ...
bq. Should we move MultiFacetsAccumulator somewhere else
You're right! It was left there by mistake because I renamed
RangeAccumulatorWrapper. Will move.
{quote}
Hmm, can we fix that? (So that the order of the results matches the
order of the requests).
{quote}
I don't know how important it is ... none of our tests depend on it, and it's
not clear to me how to fix it at all. FA.create() is a factory method. If it
returns a single Accumulator, then it happens already (order is maintained).
MultiFacetAccum loses the order. Maybe if we passed it the list of facet
requests it could re-order them after accumulation, but I don't know how
important it is... an app can put the List<FacetResult> in a Map, and do
lookups? Also, as a generic MultiFA, it's not easier to determine from which FA
a source FacetRequest came?
bq. I think we can now simplify TestDrillSideways
You're right. Done.
> 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
>
> Attachments: LUCENE-4985.patch, LUCENE-4985.patch
>
>
> 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]