Hi Shay, I think IndexWriter.getReader from LUCENE-1516 in trunk is what you're talking about? It pools readers internally so there's no need to call IndexReader.reopen, one simply calls IW.getReader to get new readers containing recent updates.
-J BTW I replied to the message on java-u...@lucene.apache.org. On Thu, May 14, 2009 at 6:37 PM, Shay Banon <kim...@gmail.com> wrote: > > Hi, > > I just had a look at the job done in IndexWriter in order to get an > IndexReader with all the current ongoing changes done using the > IndexWriter. > This feature is very useful, and I was wondering if another feature, which > (I think) is simple to implement (compared to the previous one) might make > sense. > > Many times, an application opens an IndexWriter, does whatever changes it > does, and then commits the changes. It would be nice to get an IndexReader > (read only one is fine) that corresponds to the committed (or even closed) > IndexWriter. This will allow for a cache of IndexReader that is already > used > to be updated with a fresh IndexReader, without the need to reopen one > (which should be slower than opening one based on the IndexWriter > information). The main difference is the fact that the mentioned > IndexReader > could still be reopened without the need to throw an > AlreadyClosedException. > > Does it make sense? > > Cheers, > Shay > -- > View this message in context: > http://www.nabble.com/Getting-an-IndexReader-from-a-committed-IndexWriter-tp23551978p23551978.html > Sent from the Lucene - Java Developer mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
