From lucene-user-return-1617-jakarta-archive-lucene-user=jakarta.apache.org@jakarta.apache.org Fri May 03 09:53:04 2002 Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 36814 invoked from network); 3 May 2002 09:53:04 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 May 2002 09:53:04 -0000 Received: (qmail 2284 invoked by uid 97); 3 May 2002 09:53:16 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@nagoya.betaversion.org Received: (qmail 2176 invoked by alias); 3 May 2002 09:53:16 -0000 Delivered-To: jakarta-archive-lucene-user@jakarta.apache.org Received: (qmail 2137 invoked by uid 97); 3 May 2002 09:53:15 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 2125 invoked by uid 98); 3 May 2002 09:53:15 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Date: Fri, 3 May 2002 11:53:22 +0200 Subject: Re: Homogeneous vs Heterogeneous indexes (was: FileNotFoundException) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) From: petite_abeille To: "Lucene Users List" Content-Transfer-Encoding: 7bit In-Reply-To: <3CD05137.2020103@earthlink.net> Message-Id: <9ADEA8AC-5E7B-11D6-BFCD-000393760B7E@mac.com> X-Mailer: Apple Mail (2.481) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wednesday, May 1, 2002, at 10:33 PM, Dmitry Serebrennikov wrote: > I think so... I guess you have many kinds of documents that have some > fields in common and some unique? Yes. I'm using Lucene as a backbone for a kind of oodbms. Therefore you can index any type of object that may greatly vary in their complexity. > Nope, just the files for the new segment. Well, I think the segments > and deleted files might have "segments.new" and "deleted.new" while > they are being modified, with the old ones removed and new ones renamed > afterwards. Good. > It will optimize more often and, since optimization replaces all > segments with one, the number of files will drop. However, the old > files will stay around until they are no longer in use by pre-existing > IndexReader instances, so that may be another catch. Ok, seems to be consistent with what I'm seeing. Thanks for your explanation. PA. -- To unsubscribe, e-mail: For additional commands, e-mail: