[ 
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]

Reply via email to