[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657403#action_12657403
]
Michael McCandless commented on LUCENE-1483:
--------------------------------------------
{quote}
> Why do we need the new DocCollector? Is this really needed? Would it be not
> OK to just add the offset before calling collect()?
{quote}
I'd like to allow for 'expert' cases, where the collector is told when
we advance to the next sequential reader and can do something at that
point (like our sort-by-field collector does).
But then still allow for 'normal' cases, where the collector is
unchanged with what we have today (ie it receives the "real" docID).
The core collectors would use the expert API to eke out all
performance; external collectors can use either, but the 'normal' one
would be simplest (and match back compat).
So then how to "implement" this approach... I would actually be fine
with keeping HitCollector, adding a default "setNextReader" method,
that either throws UOE or (if we are strongly against exceptions)
returns "false" indicating it cannot handle sequential readers.
Then when we run searches we simply check if the collector is an
"expert" one (does not throw UOE or return false from setNextReader)
and if it isn't we wrap it with DocBaseCollector (which adds the doc
base for every collect() call).
> Change IndexSearcher to use MultiSearcher semantics for multiple subreaders
> ---------------------------------------------------------------------------
>
> Key: LUCENE-1483
> URL: https://issues.apache.org/jira/browse/LUCENE-1483
> Project: Lucene - Java
> Issue Type: Improvement
> Affects Versions: 2.9
> Reporter: Mark Miller
> Priority: Minor
> Attachments: LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch,
> LUCENE-1483.patch, LUCENE-1483.patch, LUCENE-1483.patch
>
>
> FieldCache and Filters are forced down to a single segment reader, allowing
> for individual segment reloading on reopen.
--
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
