Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: domain of yseeley@gmail.com designates
 64.233.166.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=iZF+y6Iowq/A+dTWQ9j+/gT6Z1qRAbtG+APtaIVWEOH8IbCLc1zh1aR+w+dpJvfijmblwmFQCe6EMC4UQU9j5FZ8+9gi6XJEgQP1TxfykInUgh2HWHcfLHmsQcfrXZeTzmXws69ywoZ2lwixFna6Ftn8oMfp2Wu/h2ky6EcTXUs=
Message-ID: <c68e39170607121252r7142899hd4d7b711f82c1b27@mail.gmail.com>
Date: Wed, 12 Jul 2006 15:52:31 -0400
From: "Yonik Seeley" <yseeley@gmail.com>
To: java-dev@lucene.apache.org
Subject: Re: [jira] Commented: (LUCENE-565) Supporting deleteDocuments in
 IndexWriter (Code and Performance Results Provided)
In-Reply-To: <c7b302c50607121228p19955886k91b518c4f563223f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <14645793.1152156330186.JavaMail.jira@brutus>
	 <C7CEFFC0-544E-461D-83AB-F7A70EE02DA2@ix.netcom.com>
	 <c68e39170607060850x69218b97q879d1b092163827a@mail.gmail.com>
	 <20060707130551.GA10773@fermat.math.technion.ac.il>
	 <c68e39170607071043o17327d9ds6015be65e6b800c2@mail.gmail.com>
	 <c7b302c50607092125j43844691q4e91ad3793dd2522@mail.gmail.com>
	 <c68e39170607100927v74d67e53q43c0efe764010dc@mail.gmail.com>
	 <c7b302c50607121228p19955886k91b518c4f563223f@mail.gmail.com>

On 7/12/06, Ning Li <ning.li.li@gmail.com> wrote:
> > 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?
>
> What do you think can be best achieved by using the public APIs of
> IndexReader and IndexWriter?

I'm not sure I understand your question.... you mean why would one
want to stick to public APIs? The IndexWriter class them is a simpler
implementation that's easier to understand and verify correctness,
easier to make changes+enhancements to, easier to maintain.  The new
class (NewIndexModifier) is not as tightly coupled and doesn't have to
be inspected and fixed every time a change to IndexModifier is made.

Overwriting documents (via delete then add) or interleaving adds and
deletes is a common Lucene usecase... it would be a good thing if this
functionality were somewhere in Lucene in an efficient form.

If it can be done in a separate class, using public APIs (or at least
with a minimum of protected access), without a loss in performance,
then that's the way to go IMO.  If you lose too much performance, then
we start looking at the bare minimum functionality we need to expose
to recover that performance.

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

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