lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Grant Ingersoll (JIRA)" <>
Subject [jira] Commented: (LUCENE-2691) Consolidate Near Real Time and Reopen API semantics
Date Wed, 13 Oct 2010 15:10:32 GMT


Grant Ingersoll commented on LUCENE-2691:

The semantics of reopen is you get a new Reader.  If an optimize was done between open and
reopen of the IR, you are getting an all new Reader.  Should that get rid of reopen, too?

As I said above, though, I'm fine w/ dropping the reopen one and just keeping open(IW).  I
care more about the fact that it is non-intuitive to ask a Writer for a Reader and this silly
notion we have right now that if you want "fast reopen" you should reopen off of the IR, but
if you want "really fast reopen" you should open off the Writer.  In fact, maybe we should
just drop reopen all together and simply have all points go through the open() method, by
adding:  open(IndexReader)

> Consolidate Near Real Time and Reopen API semantics
> ---------------------------------------------------
>                 Key: LUCENE-2691
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Improvement
>            Reporter: Grant Ingersoll
>            Assignee: Grant Ingersoll
>            Priority: Minor
>             Fix For: 4.0
>         Attachments: LUCENE-2691.patch, LUCENE-2691.patch
> We should consolidate the IndexWriter.getReader and the IndexReader.reopen semantics,
since most people are already using the IR.reopen() method, we should simply add::
> {code}
> IR.reopen(IndexWriter)
> {code}
> Initially, it could just call the IW.getReader(), but it probably should switch to just
using package private methods for sharing the internals

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