lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: Exposing IndexReader commit()
Date Mon, 11 Dec 2006 20:26:35 GMT
Hi Otis,

What is your real usecase here?  Is it to make sure deletes are
flushed in the event of a crash?  Otherwise I don't see the problem
with delaying deletes.

-Yonik Solr, the open-source Lucene search server

On 12/4/06, Otis Gospodnetic <> wrote:
> Hello,
> I'm wondering about opening up commit() in IndexReader.  It's currently "protected".
> We'd like to be able to control the flushing of deletes to disk, and it looks like that's
what IndexReader's commit() does.  We tried extending SegmentReader with our own version that
overrides commit() and let's us call it.  This worked for indices with a single segment, because
they are read by SegmentReader.  However, this didn't work with multi-segment indices, because
unlike SegmentReader, MultiReader doesn't know how to dynamically load a custom MultiReader.
> Both SegmentReader and MultiReader extend IndexReader, which contains that protected
> Next, we thought we'd try extending IndexReader and using our own IndexReader, but since
Segment|MultiReader extend IndexReader directly, I don't think this approach would work.
> In the end, we just made commit() public in IndexReader, and solved our problem for both
single and multi-segment indices.
> Is there a better way to control flushing to disk without closing and re-opening an IndexReader,
which is more expensive than just commit()ing.
> If not, what do you think about making commit() public and javadocing it with "Expert:...."?
> Thanks,
> Otis

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

View raw message