lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yonik Seeley" <>
Subject Re: [jira] Commented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided)
Date Fri, 14 Jul 2006 14:22:51 GMT
On 7/14/06, Ning Li <> 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

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 Solr, the open-source Lucene search server

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

View raw message