Re: Exposing IndexReader commit()

2006-12-11 Thread Otis Gospodnetic
ent: Monday, December 11, 2006 8:46:15 PM Subject: Re: Exposing IndexReader commit() On 12/11/06, robert engels <[EMAIL PROTECTED]> wrote: > I think the high-level case is that if the index is shared, you want > the other readers to be able to see the updated deletes if they are > no

Re: Exposing IndexReader commit()

2006-12-11 Thread Yonik Seeley
On 12/11/06, robert engels <[EMAIL PROTECTED]> wrote: I think the high-level case is that if the index is shared, you want the other readers to be able to see the updated deletes if they are notified to reread the index (using something like reopen). It still seems like an odd usecase for one t

Re: Exposing IndexReader commit()

2006-12-11 Thread robert engels
I think the high-level case is that if the index is shared, you want the other readers to be able to see the updated deletes if they are notified to reread the index (using something like reopen). On Dec 11, 2006, at 2:59 PM, Yonik Seeley wrote: On 12/11/06, Otis Gospodnetic <[EMAIL PROTECT

Re: Exposing IndexReader commit()

2006-12-11 Thread Yonik Seeley
On 12/11/06, Otis Gospodnetic <[EMAIL PROTECTED]> wrote: I believe (another colleague did work around this) the use case is the desire to flush the deletes without having to close the reader and reopen it, which is expensive because of FieldCache population. Yes, but that doesn't answer *why*

Re: Exposing IndexReader commit()

2006-12-11 Thread robert engels
o: java-dev@lucene.apache.org Sent: Monday, December 11, 2006 2:51:14 PM Subject: Re: Exposing IndexReader commit() Attached is the current version of reopen(). On Dec 11, 2006, at 1:28 PM, Otis Gospodnetic wrote: Does anyone have any thoughts or feelings about this? There is also Ro

Re: Exposing IndexReader commit()

2006-12-11 Thread Otis Gospodnetic
: java-dev@lucene.apache.org Sent: Monday, December 11, 2006 3:26:35 PM Subject: Re: Exposing IndexReader commit() 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.

Re: Exposing IndexReader commit()

2006-12-11 Thread Yonik Seeley
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 http://incubator.apache.org/solr Solr, the open-source Lucene search server On 12/4/06, Otis Gospodnetic <[EMAIL PROTECTED]

Re: Exposing IndexReader commit()

2006-12-11 Thread Otis Gospodnetic
Eh, didn't make it. JIRA? Thanks, Otis - Original Message From: robert engels <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, December 11, 2006 2:51:14 PM Subject: Re: Exposing IndexReader commit() Attached is the current version of reopen(). On Dec 11,

Re: Exposing IndexReader commit()

2006-12-11 Thread robert engels
couldn't find this in JIRA - is it sharable?) Thanks, Otis - Original Message From: Otis Gospodnetic <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, December 4, 2006 5:35:20 PM Subject: Exposing IndexReader commit() Hello, I'm wondering about openin

Re: Exposing IndexReader commit()

2006-12-11 Thread Otis Gospodnetic
Otis Gospodnetic <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Monday, December 4, 2006 5:35:20 PM Subject: Exposing IndexReader commit() Hello, I'm wondering about opening up commit() in IndexReader. It's currently "protected". We'd like to be able to control

Exposing IndexReader commit()

2006-12-04 Thread Otis Gospodnetic
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()