[ 
https://issues.apache.org/jira/browse/LUCENE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13222368#comment-13222368
 ] 

Martijn van Groningen commented on LUCENE-3778:
-----------------------------------------------

{quote}
One can actually use GroupingSearch in a shard'd env, on each shard,
right? It's just that then you merge them like normal on the front
end (ie, TopGroups.merge). Is that the only reason for the "... in a
non distributed environment" javadoc warning?
{quote}
In a sharded env one needs to first execute all the first pass collector on all 
shards, merge the returned search groups, execute the second pass search (with 
the top N merged search groups as argument) on most of the shards and finally 
merge the TopGroups from all shards into a topN TopGroups. Also grouping by 
docblock and grouping features like allGroups and groupHead don't work in a 
normal sharded environment (unless you partition the groups properly). The docs 
caching also only makes sense when performing grouping on a local index. This 
usage is very different then non distributed grouping, that is why I think it 
is better to have a separate grouping convenience class for distributed 
grouping (DistributedGroupSearch?). 

bq. Maybe the ctor should take docValuesType / diskResidentValues
Makes sense!

bq. Maybe you should pass the groupSort, groupsOffset, groupsLimit to the 
search method (instead of setters)?
Maybe we just should have defaults for these options? Sort.RELEVANCE, 0 and 10?
                
> Create a grouping convenience class
> -----------------------------------
>
>                 Key: LUCENE-3778
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3778
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: modules/grouping
>            Reporter: Martijn van Groningen
>         Attachments: LUCENE-3778.patch
>
>
> Currently the grouping module has many collector classes with a lot of 
> different options per class. I think it would be a good idea to have a 
> GroupUtil (Or another name?) convenience class. I think this could be a 
> builder, because of the many options 
> (sort,sortWithinGroup,groupOffset,groupCount and more) and implementations 
> (term/dv/function) grouping has.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to