[
https://issues.apache.org/jira/browse/LUCENE-1849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747059#action_12747059
]
Tim Smith commented on LUCENE-1849:
-----------------------------------
I guess the question is: what variations do we provide helper Collector
implementations for?
seems like there's a bunch of possibilities (depending on how far you go)
thats why i initially proposed AbstractCollector (storing everything that was
set (IndexReader, Scorer, docBase))
the amount of memory and time used to set 2 pointers and an int per segment
almost seems irrelevant for this Collector implementation aid (and if you
really care about those few bytes and cpu cycles, you can directly implement
Collector)
> Add OutOfOrderCollector and InOrderCollector subclasses of Collector
> --------------------------------------------------------------------
>
> Key: LUCENE-1849
> URL: https://issues.apache.org/jira/browse/LUCENE-1849
> Project: Lucene - Java
> Issue Type: Wish
> Components: Search
> Affects Versions: 2.9
> Reporter: Tim Smith
> Priority: Minor
> Fix For: 2.9
>
>
> I find myself always having to implement these methods, and i always return a
> constant (depending on if the collector can handle out of order hits)
> would be nice for these two convenience abstract classes to exist that
> implemented acceptsDocsOutOfOrder() as final and returned the appropriate
> value
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
