lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <>
Subject [jira] Commented: (LUCENE-743) IndexReader.reopen()
Date Mon, 22 Oct 2007 20:37:51 GMT


Michael McCandless commented on LUCENE-743:

    * MultiReader/ParallelReader must not incref the subreaders on open()
      as you said. But on reopen() it must incref the subreaders that
      haven't changed and thus are shared with the old MultiReader/
      ParallelReader. This further means, that the re-opened MultiReader/
      ParallelReader must remember which of the subreaders to decref on
      close(), right?

Hmm, right.  MultiReader/ParallelReader must keep track of whether it
should call decref() or close() on each of its child readers, when it
itself is closed.

    * If we change ensureOpen() like you suggest, then the user might
      still be able to use reader1 (in my example), even after
      reader1.close() was explicitly called. Probably not a big deal?

I think this is OK?

> 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-take2.patch, lucene-743.patch,
lucene-743.patch, lucene-743.patch,,, varient-no-isCloneSupported.BROKEN.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