OK I just committed it -- thanks!
Mike
On Mon, Oct 12, 2009 at 5:01 PM, Jake Mannix <jake.man...@gmail.com> wrote:
> That seems a lot more straightforward Mike, thanks.
>
> -jake
>
> On Mon, Oct 12, 2009 at 1:56 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> I agree, the javadocs could be improved. How about something like
>> this for the first 2 paragraphs:
>>
>> * Returns a readonly reader, covering all committed as
>> * well as un-committed changes to the index. This
>> * provides "near real-time" searching, in that changes
>> * made during an IndexWriter session can be quickly made
>> * available for searching without closing the writer nor
>> * calling {...@link #commit}.
>> *
>> * <p>Note that this is functionally equivalent to calling
>> * {#commit} and then using {...@link IndexReader#open} to
>> * open a new reader. But the turarnound time of this
>> * method should be faster since it avoids the potentially
>> * costly {...@link #commit}.<p>
>>
>> Mike
>>
>> On Mon, Oct 12, 2009 at 4:35 PM, Jake Mannix <jake.man...@gmail.com>
>> wrote:
>> > Thanks Yonik,
>> >
>> > It may be surprising, but in fact I have read that
>> > javadoc. It talks about not needing to close the
>> > writer, but doesn't specifically talk about the what
>> > the relationship between commit() calls and
>> > getReader() calls is. I suppose I should have
>> > interpreted:
>> >
>> > "@returns a new reader which contains all
>> > changes..."
>> >
>> > to mean "all uncommitted changes", but why
>> > is it so obvious that what could be happening
>> > is that it only "returns all changes since the last
>> > commit, but without touching disk because it
>> > has docs in memory as well"?
>> >
>> > -jake
>> >
>> > On Mon, Oct 12, 2009 at 1:26 PM, Yonik Seeley <
>> yo...@lucidimagination.com>wrote:
>> >
>> >> Guys, please - you're not new at this... this is what JavaDoc is for:
>> >>
>> >> /**
>> >> * Returns a readonly reader containing all
>> >> * current updates. Flush is called automatically. This
>> >> * provides "near real-time" searching, in that changes
>> >> * made during an IndexWriter session can be made
>> >> * available for searching without closing the writer.
>> >> *
>> >> * <p>It's near real-time because there is no hard
>> >> * guarantee on how quickly you can get a new reader after
>> >> * making changes with IndexWriter. You'll have to
>> >> * experiment in your situation to determine if it's
>> >> * fast enough. As this is a new and experimental
>> >> * feature, please report back on your findings so we can
>> >> * learn, improve and iterate.</p>
>> >> *
>> >> * <p>The resulting reader supports {...@link
>> >> * IndexReader#reopen}, but that call will simply forward
>> >> * back to this method (though this may change in the
>> >> * future).</p>
>> >> *
>> >> * <p>The very first time this method is called, this
>> >> * writer instance will make every effort to pool the
>> >> * readers that it opens for doing merges, applying
>> >> * deletes, etc. This means additional resources (RAM,
>> >> * file descriptors, CPU time) will be consumed.</p>
>> >> *
>> >> * <p>For lower latency on reopening a reader, you should
>> >> * call {...@link #setMergedSegmentWarmer} to
>> >> * pre-warm a newly merged segment before it's committed
>> >> * to the index. This is important for minimizing
>> >> * index-to-search delay after a large merge. </p>
>> >> *
>> >> * <p>If an addIndexes* call is running in another thread,
>> >> * then this reader will only search those segments from
>> >> * the foreign index that have been successfully copied
>> >> * over, so far</p>.
>> >> *
>> >> * <p><b>NOTE</b>: Once the writer is closed, any
>> >> * outstanding readers may continue to be used. However,
>> >> * if you attempt to reopen any of those readers, you'll
>> >> * hit an {...@link AlreadyClosedException}.</p>
>> >> *
>> >> * <p><b>NOTE:</b> This API is experimental and might
>> >> * change in incompatible ways in the next release.</p>
>> >> *
>> >> * @return IndexReader that covers entire index plus all
>> >> * changes made so far by this IndexWriter instance
>> >> *
>> >> * @throws IOException
>> >> */
>> >> public IndexReader getReader() throws IOException {
>> >>
>> >>
>> >> -Yonik
>> >> http://www.lucidimagination.com
>> >>
>> >>
>> >> On Mon, Oct 12, 2009 at 4:18 PM, John Wang <john.w...@gmail.com> wrote:
>> >> > Oh, that is really good to know!
>> >> > Is this deterministic? e.g. as long as writer.addDocument() is called,
>> >> next
>> >> > getReader reflects the change? Does it work with deletes? e.g.
>> >> > writer.deleteDocuments()?
>> >> > Thanks Mike for clarifying!
>> >> >
>> >> > -John
>> >> >
>> >> > On Mon, Oct 12, 2009 at 12:11 PM, Michael McCandless <
>> >> > luc...@mikemccandless.com> wrote:
>> >> >
>> >> >> Just to clarify: IndexWriter.newReader returns a reader that searches
>> >> >> uncommitted changes as well. Ie, you need not call
>> IndexWriter.commit
>> >> >> to make the changes visible.
>> >> >>
>> >> >> However, if you're opening a reader the "normal" way
>> >> >> (IndexReader.open) then it is necessary to first call
>> >> >> IndexWriter.commit.
>> >> >>
>> >> >> Mike
>> >> >>
>> >> >> On Mon, Oct 12, 2009 at 5:24 AM, melix <cedric.champ...@lingway.com>
>> >> >> wrote:
>> >> >> >
>> >> >> > Hi,
>> >> >> >
>> >> >> > I'm going to replace an old reader/writer synchronization mechanism
>> we
>> >> >> had
>> >> >> > implemented with the new near realtime search facilities in Lucene
>> >> 2.9.
>> >> >> > However, it's still a bit unclear on how to efficiently do it.
>> >> >> >
>> >> >> > Is the following implementation the good way to do achieve it ? The
>> >> >> context
>> >> >> > is concurrent read/writes on an index :
>> >> >> >
>> >> >> > 1. create a Directory instance
>> >> >> > 2. create a writer on this directory
>> >> >> > 3. on each write request, add document to the writer
>> >> >> > 4. on each read request,
>> >> >> > a. use writer.getReader() to obtain an up-to-date reader
>> >> >> > b. create an IndexSearcher with that reader
>> >> >> > c. perform Query
>> >> >> > d. close IndexSearcher
>> >> >> > 5. on application close
>> >> >> > a. close writer
>> >> >> > b. close directory
>> >> >> >
>> >> >> > While this seems to be ok, I'm really wondering about the
>> performance
>> >> of
>> >> >> > opening a searcher for each request. I could introduce some kind of
>> >> delay
>> >> >> > and cache a searcher for some seconds, but I'm not sure it's the
>> best
>> >> >> thing
>> >> >> > to do.
>> >> >> >
>> >> >> > Thanks,
>> >> >> >
>> >> >> > Cedric
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > View this message in context:
>> >> >>
>> >>
>> http://www.nabble.com/Realtime-search-best-practices-tp25852756p25852756.html
>> >> >> > Sent from the Lucene - Java Users mailing list archive at
>> Nabble.com.
>> >> >> >
>> >> >> >
>> >> >> >
>> ---------------------------------------------------------------------
>> >> >> > To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> >> >> > For additional commands, e-mail: java-user-h...@lucene.apache.org
>> >> >> >
>> >> >> >
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> >> >> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: java-user-h...@lucene.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-user-h...@lucene.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-user-h...@lucene.apache.org
