[
https://issues.apache.org/jira/browse/LUCENE-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655812#action_12655812
]
Doug Cutting commented on LUCENE-1483:
--------------------------------------
> If users are using a HitCollector as a ref to a trunk HitCollector that
> becomes a Hitable, won't their code break?
Lucene never passes someone a HitCollector that they didn't create. So all the
classes that folks create may need to remain subclasses of HitCollector, but
classes used internally do not need to, and we can deprecate all public
HitCollector implementations and provide new versions that extend Hitable.
http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/search/class-use/HitCollector.html
Does that address your concern?
I'm not too fond of Hitable, but can't think of anything better. With that
name, the method might better be called hit() than collect(), but that's a more
invasive change. DocCollector? Collector?
> 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
>
>
> 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
