lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doron Cohen <DOR...@il.ibm.com>
Subject Re: modify existing non-indexed field
Date Sat, 08 Jul 2006 20:16:38 GMT
> From what you said, I'm thinking of switching to IndexModifier.

Yes, IndexModifier would synchronize add/delete.  One should notice the
performance comment in IndexModifier
http://lucene.apache.org/java/docs/api/org/apache/lucene/index/IndexModifier.html
 - "While you can freely mix calls to add() and delete() using this class,
you should batch you calls for best performance. For example, if you want
to update 20 documents, you should first delete all those documents, then
add all the new documents."

> Before that,
> I have a few more questions:
> 1. without using an exclusive lock, is there anyway to new a
IndexModifier
> or IndexWritter while IndexReaders are serving search queries? or do I
have
> to new a IndexWriiter when system starts and keep it open all the time?

It is possible to open an IndexWriter while a searcher is open. For search
to "feel" the changes made by the writer, a new searcher should be opened
(after the writer is closed or after it writes from memory to disk. With
IndexModifier, the flush() method can be used.)

> 2. When adding a new document, and calling optimize(), do I have to close
> the readers/searchers?

No need to close searchers.
"Lucene in Action" book, chapter 2.9 explains this much better than I can,
and draws a table of "what can run with what else".

> 3. In my case, updating non-idexed fields happens a lot, can you explain
the
> side data store in more detail? I'm not sure with this approach. Do you
mean
> creating a separate database and stores lucene's ids?

Yes, a separate store, with mapping from ID to mutable fields of the
document with this ID. When adding a doc to Lucene, a stored field would be
added to contain the ID of the added doc. At search time, the ID would be
retrieved for that doc, and can be used to fetch the mutable fields from
the separate store. But I think it is better to start with the simpler
approach - updating documents in Lucene - and turn to something more
complex only if there are unacceptable performance issues due to updating
these documents fields.

Regards,
Doron


---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message