lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morus Walter <morus.wal...@tanto.de>
Subject Re: IndexReader.close() semantics and optimize -- Re: problem with locks when updating the data of a previous stored document
Date Fri, 17 Sep 2004 06:15:50 GMT
David Spencer writes:
> Crump, Michael wrote:
> 
> > You have to close the IndexReader after doing the delete, before opening the IndexWriter
for the addition.  See information at this link:
> > 
> > http://wiki.apache.org/jakarta-lucene/UpdatingAnIndex
> 
> Recently I thought I observed that if I use this batch update idiom (1st 
> delete the changed docs, then add them), it seems that 
> IndexReader.close() does not flush/commit the deletions - rather 
> IndexWriter.optimize() does.
> 
> I may have been confused and should retest this, but regardless, the 
> javadoc seems unclear. close() says it "*saves* deletions to disk". What 
> does it mean to save a deletion? Save a pending one, or commit it 
> (commit -> really delete it)?
> 
My understanding is, that saving makes sure, that index searcher opened after
the close will take the deletions into account.
Deletion in lucene is in fact a two phase process:
a) delete -> document is marked deleted but not removed from the index.
	  low level apis (such as list terms) will still see the content
	  from deleted documents 
	  Search takes the delete flag into account and removes deleted
	  documents from the result list.
	  (I think this also means that the deleted documents still 
	  contribute to term frequencies)
b) remove deleted documents
   this is done during optimize

Morus

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


Mime
View raw message