I like the name BufferedDeletingIndexWriter best so far.
Chris Hostetter wrote: > from an API standpoint, it seems like this could easily replace the > current IndexModifier (which would have the nice side effect of > resolving the issue of wether the name NewIndexModifier is good > enough) assuming the semantics of the classes/methdos are the same > -- i'm not sure if they are. The one method missing vs IndexModifier, which prevents this being a drop in replacement, is deleteDocument(int docNum). This specific issue was discussed here: https://issues.apache.org/jira/browse/LUCENE-565#action_12430130 and I would tend to agree with that logic (exposing a deleteDocument(int docNum) is dangerous), meaning we can't drop in replace the current IndexModifier. Maybe we could deprecate the existing IndexModifier? > skimming hte history of LUCENE-565 it's not clear to me why this was > implemented as a new class with the name NewIndexModifier ... was > that just how it evolved organicly? Well, the patch started life as direct improvements to IndexWriter. But people were concerned w/ that approach and suggested enabling sub-classing of IndexWriter instead, which lead to the current NewIndexModifier class. Long-ish term I think we should aim for one reader class (IndexReader) that you use to do read-only things and one writer class (NewIndexModifier being closest to this now) to make changes (adds, deletes, optimize, etc.) to an index. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
