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.177 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=qYM2UcS3CkBfM0EqAKkMv3WGYDf9LZ/PK6fGQhx/yDxcCd8tjDmvvlJnxG7hL+OyIoBh4QhBLaT1bHtk++P44/wn6EZr9/0BsJukPHMcU2Ic6MkZETtSMm8tmlvvb9GejxpJeIfdkWP75LafcJH0AgeS3tCDxMD81ORPnmwQlE8=
Message-ID: <c68e39170607140722x7b12cf52n56a1879978d4fd11@mail.gmail.com>
Date: Fri, 14 Jul 2006 10:22:51 -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: <c7b302c50607132231w375f7ef1v1e2895115a7fabb6@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>
	 <20060707130551.GA10773@fermat.math.technion.ac.il>
	 <c68e39170607071043o17327d9ds6015be65e6b800c2@mail.gmail.com>
	 <c7b302c50607092125j43844691q4e91ad3793dd2522@mail.gmail.com>
	 <c68e39170607100927v74d67e53q43c0efe764010dc@mail.gmail.com>
	 <c7b302c50607121228p19955886k91b518c4f563223f@mail.gmail.com>
	 <c68e39170607121252r7142899hd4d7b711f82c1b27@mail.gmail.com>
	 <c7b302c50607121314t6561f920ocb18a70f568c9a65@mail.gmail.com>
	 <c68e39170607131407r7815a466h2259c238adb5ca0a@mail.gmail.com>
	 <c7b302c50607132231w375f7ef1v1e2895115a7fabb6@mail.gmail.com>

On 7/14/06, Ning Li <ning.li.li@gmail.com> wrote:
> I have viewed "delete by term" (which is supported by IndexReader and
> NewIndexModifier) as a kind of "delete by query", not "delete by id".
>
> If I replace Term in DeleteTerm with Query (or query string), and
> re-define applyDeletesSelectively() as follows (this is not the best
> possible implementation, but you get the idea):
>
> I hope the point is clear now. :-) The patch was designed so that it
> can support "delete by term" and even "delete by query" in general,

Hey, you're moving the goalposts ;-)
You proposed a specific patch, and it certtainly doesn't have support
for delete-by-query.

But yes, using the approach of your first patch, you could come up
with another that could more efficiently support delete-by-query...
there would probably need to be a little more work to do it
efficiently though (w/o creating scorers for each individual reader
perhaps).

If one is going to be able to support deleteByQuery, why not a full
IndexSearcher/IndexWriter combination?

As far as implementation, right now NewIndexModifier overrides and
reimplements much of the guts of IndexWriter.  Is there a way of
lowering that profile by providing some extension points, or places to
hook into IndexWriter events (like before the ram segment is going to
be flushed)?  Maybe IndexWriter could call a specific method on a
callback interface with List<Reader> that returns a list of document
ids to delete (through an efficient interface such as HitCollector or
Matcher of course).   Something like that would be much more general
if it's doable.

-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