lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Thu, 19 Jul 2007 00:41:05 GMT


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:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Otis Gospodnetic
>            Assignee: Michael Busch
>            Priority: Minor
>         Attachments:,,
> 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:
For additional commands, e-mail:

View raw message