: It's a temporary name, no? In the end we probably want to keep the : _name_ IndexWriter, so why not just it IndexWriter2 and when we are : happy with it, we make it be the new IndexWriter and we deprecate IW2.
Um... actually that's a really good point, this is first and formost an extension of IndexWriter ... is there any reason not to rename "NewIndexModifier" as "IndexWriter" (refactoring the existing IndexWriter code into it, or moving the renaming the current IndexWriter to "OldIndexWriter", or "NonDeletingIndexWriter") the only reason i can think of not to do this would be if we are worried about people who currently subclass IndexWriter getting a change in behavior if we change the INdexWRiter out from under them ... is this a signifcant concern? NewIndexModifier doesn't seem to change any of hte semantics of the IndexWriter methods it extends. ----- Original Message ---- From: robert engels <[EMAIL PROTECTED]> To: java-dev@lucene.apache.org Sent: Thursday, February 8, 2007 4:08:31 AM Subject: Re: NewIndexModifier - - - DeletingIndexWriter Maybe IndexMaintainer or IndexUpdater ? On Feb 8, 2007, at 2:59 AM, Chris Hostetter wrote: > : > : As 2.1 is soon coming, I wonder if NewIndexModifier is a proper > name for > : the public API. > : (It would be the first NewXYZ and there is no OldXYZ either...) > : > : How about renaming it to something like DeletingIndexWriter? > > I haven't been following the Jira issue that closely (LUCENE-565), > but as > i recall the name question comes up because the class originally > intended > to replace IndexModifier, but it's API/purpose has evolved so that > it is > no longer a suitable "drop in replacement" for the current > IndexModifier > is that correct? > > NewIndexModifier currently subclasses IndexWriter and adds the > following > public methods... > > public void setMaxBufferedDeleteTerms(int maxBufferedDeleteTerms) > public int getMaxBufferedDeleteTerms() > public void updateDocument(Term term, Document doc) > public void updateDocument(Term term, Document doc, Analyzer > analyzer) > public synchronized void deleteDocuments(Term term) > public synchronized void deleteDocuments(Term[] terms) > > 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. > > 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? > > > if it's not possible to make this class replace IndexModifier, then > DeletingIndexWriter or BufferedDeletingIndexWriter seem like they > would be > fine to me. > > -Hoss > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] : : --------------------------------------------------------------------- : To unsubscribe, e-mail: [EMAIL PROTECTED] : For additional commands, e-mail: [EMAIL PROTECTED] : -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
