lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: NewIndexModifier - - - DeletingIndexWriter
Date Thu, 08 Feb 2007 19:50:05 GMT

: 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 <>
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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

: ---------------------------------------------------------------------
: To unsubscribe, e-mail:
: For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message