lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Busch (JIRA)" <>
Subject [jira] Updated: (LUCENE-743) IndexReader.reopen()
Date Wed, 01 Aug 2007 21:41:53 GMT


Michael Busch updated LUCENE-743:

    Attachment: lucene-743.patch

Now, after LUCENE-781, LUCENE-970 and LUCENE-832 are committed, I updated the latest
patch here, which was now easier because MultiReader is now separated into two classes.

   * As Hoss suggested I added the reopen() method to IndexReader non-static. 
   * MultiReader and ParallelReader now overwrite reopen() to reopen the subreaders
   * FilteredReader also overwrites reopen(). It checks if the underlying reader has
     changed, and in that case returns a new instance of FilteredReader.
I think the general contract of reopen() should be to always return a new IndexReader 
instance if it was successfully refreshed and return the same instance otherwise, 
because IndexReaders are used as keys in caches.
A remaining question here is if the old reader(s) should be closed then or not.
This patch closes the old readers for now, if we want to change that we probably have 
to add some reference counting mechanism, as Robert suggested already. Then I would
also have to change the SegmentReader.reopen() implementation to clone resources like
the dictionary, norms and delete bits. 
I think closing the old reader is fine. What do others think? Is keeping the old 
reader after a reopen() a useful usecase?

> IndexReader.reopen()
> --------------------
>                 Key: LUCENE-743
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>            Reporter: Otis Gospodnetic
>            Assignee: Michael Busch
>            Priority: Minor
>             Fix For: 2.3
>         Attachments:, lucene-743.patch, lucene-743.patch, lucene-743.patch,,
> 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