On 7/10/06, Ning Li <[EMAIL PROTECTED]> wrote:
Almost all the Lucene newbies
that I know went through this learning curve of realizing you have to
batch inserts and deletes to achieve good performance.

I agree that having the ability of interleave inserts and deletes to
users of Lucene is a good thing.  That alone doesn't mean that it's
implementation should live in the IndexWriter.

An implementation could live in IndexModifier, or there could be
multiple implementations, each with their own tradeoffs.  As I said
before, adding this specific implementation directly to IndexWriter
would only be warranted if it were a clear performance win over
implementing it in a higher level class.

The current implementation makes some assumptions, such as the "unique
key" is a single field, not any sort of compound key, and it doesn't
allow deletes by query.  That, coupled with a more complex
implementation makes me wary of putting it in IndexWriter.

I see you have updated the JIRA issue, creating a NewIndexModifier
that overrides many IndexWriter methods (and making them protected).
Thats a very big step in the right direction since that implementation
is now optional.

The only reservation I'd have with making the IndexWriter methods
protected and having such extensive overriding is that I'd have to
worry about NewIndexModifier (and other classes) whenever a change to
IndexWriter was made.

I'll rephrase my original question:
 When implementing NewIndexModifier, what type of efficiencies do we
get by using the new protected methods of IndexWriter vs using the
public APIs of IndexReader and IndexWriter?

so ideally,
you never need to close IndexWriter! I really think it's worth it. :-)

For incremental updates, you still need to close the index writer in
order to open a new index reader that can see the changes.

-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to