Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <18666853.post@talk.nabble.com>
Date: Sat, 26 Jul 2008 06:31:49 -0700 (PDT)
From: Ajay Garg <ajaygargnsit@gmail.com>
To: java-user@lucene.apache.org
Subject: Re: Query in IndexWriter.deleteDocuments(Term term)
In-Reply-To: <18666813.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <18662995.post@talk.nabble.com>
 <FD8B25C8-BFEF-4C58-B7DD-4D705063B322@mikemccandless.com>
 <18665652.post@talk.nabble.com>
 <C172F4F4-CFDF-4585-9BAF-6AA627B9DD3A@mikemccandless.com>
 <18666813.post@talk.nabble.com>


Pardon me. But will commit() be "code-fully" equal to calling close()
followed by reinstantiating IW with create=false ??? If the above is indeed
true, I can very well begin with my work.

I ask this, because I plan to work within a fortnight, and 2.4 is still
someway away, and the primary reason I am porting to 2.3.2 (from 2.0.0), is
to have explicit commit() control in our hands. 


Ajay Garg wrote:
> 
> So commit() will be available from 2.4 onwards??
> 
> Michael McCandless-2 wrote:
>> 
>> 
>> Ajay Garg wrote:
>> 
>>> Thanks Mike. That was quite explanatory. A couple of doubts:
>> 
>> You're welcome!
>> 
>>> 1. The deletions apply to buffered as well as stored-in-RAM documents.
>>> Right. So, if the index directory contains 1 document that matches a
>>> deleteDocument query, and 1 document in RAM that contains the same
>>> deleteDocument query, then, will the document-in-index-directory be  
>>> deleted
>>> immediately, or when a flush is called. (It seems logical, that  
>>> irrespective
>>> of the location of document, "actual" deletion occurs only when a  
>>> flush is
>>> called .. just need to be doubly sure ...)
>> 
>> Well ... the "actual" deletion (visible to an IndexReader that opens  
>> the index) is only guaranteed to be performed if you call commit()  
>> (trunk) or close() (2.3, trunk) on the IW.
>> 
>> First, deleted docIDs, terms and queries are simply buffered in RAM.   
>> Then at some point (no guarantee on when) they are flushed into per- 
>> segment .del files in the directory, but, these del files are  
>> "unreferenced" (by a segments_N file) until commit() or close() is  
>> called.
>> 
>>> 2. Yes I am planning to rewrite a project using Lucene 2.3.2. So, is  
>>> the
>>> next version heading straight to 3.0 ??? (Sorry, if this question  
>>> seems to
>>> be a little out of context of the current thread)
>> 
>> The current plan is to have a 2.4 release next, then a 2.9 release and  
>> finally 3.0.  It's spelled out a bit here:
>> 
>>      http://wiki.apache.org/lucene-java/Java_1.5_Migration
>> 
>> But there are no dates attached to those bullets!
>> 
>> Mike
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Query-in-IndexWriter.deleteDocuments%28Term-term%29-tp18662995p18666853.html
Sent from the Lucene - Java Users mailing list archive at Nabble.com.


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