On Tue, Sep 22, 2009 at 3:53 PM, Grant Ingersoll <gsing...@apache.org> 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. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
