[
https://issues.apache.org/jira/browse/LUCENE-743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513772
]
Hoss Man commented on LUCENE-743:
---------------------------------
i somehow missed seeing this issues before ... i don't really understand the
details, but a few comments that come to mind...
1) this approach seems to assume that when reopening a MyMultiReader, the sub
readers will all be MySegmentReaders .. assuming we generalize this to
MultiReader/SegmentTeader, this wouldn't work in the case were people are using
a MultiReader containing other MultiReaders ... not to mention the possibility
of people who have written their own IndexReader implementations.
in generally we should probably try to approach reopening a reader as a
recursive operation if possible where each type of reader is responsible for
checking to see if it's underlying data has changed, if not return itself, if
so return a new reader in it's place (much like rewrite works for Queries)
2) there is no more commit lock correct? ... is this approach something that
can still be valid using the current backoff/retry mechanism involved with
opening segments?
> IndexReader.reopen()
> --------------------
>
> Key: LUCENE-743
> URL: https://issues.apache.org/jira/browse/LUCENE-743
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Otis Gospodnetic
> Assignee: Michael Busch
> Priority: Minor
> Attachments: IndexReaderUtils.java, MyMultiReader.java,
> MySegmentReader.java
>
>
> This is Robert Engels' implementation of IndexReader.reopen() functionality,
> as a set of 3 new classes (this was easier for him to implement, but should
> probably be folded into the core, if this looks good).
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
