lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: IndexWriter.getReader() was Re: How to leverage the LogMergePolicy "calibrateSizeByDeletes" patch in Solr ?
Date Tue, 22 Sep 2009 23:05:02 GMT
On Tue, Sep 22, 2009 at 3:53 PM, Grant Ingersoll <> wrote:

>> But, the returned reader is read-only, so you can't use it to change
>> norms, do deletes, etc.
> Yeah, but an IW can do deletes, and if the this IR is coupled to it
> anyway...

True, but IW's deletes are still buffered, and you can't delete by doc
ID with IW.

>> But Directory is too low... we could probably get by with a class that
>> holds the SegmentReader cache (currently IndexWriter.ReaderPool), and
>> the "current" segmentInfos.  IW would interact with this class to get
>> the readers it needs, for applying deletes, merging, as well as
>> posting newly flushed but not yet committed segments, and IR would
>> then pull from this class to get the latest segments in the index and
>> to checkout the readers.
> Not sure why Directory, a public well-known class, is considered too low (I
> thought you would say too high!) versus inner classes that assume an
> IndexWriter. The reason I chose Directory is because it is the common thing
> already shared between the two and it is already a public, well-known class
> that requires no extra understanding by users.  It's a first class citizen.
>  By reusing it, apps can be agnostic about where it came from, versus having
> to wire in all this new stuff to handle ReaderPools, etc. versus simply
> reusing the directory stuff.

Sorry, by "low" I meant logically Directory is a lightweight file
access API -- it's at the low level of Lucene's stack.  I'm not sure
we should overload it by storing SegmentInfos, caching SegmentReaders
in it, etc.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message