Return-Path: Delivered-To: apmail-jakarta-lucene-dev-archive@www.apache.org Received: (qmail 35612 invoked from network); 25 Sep 2004 19:10:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 25 Sep 2004 19:10:30 -0000 Received: (qmail 24316 invoked by uid 500); 25 Sep 2004 19:12:23 -0000 Delivered-To: apmail-jakarta-lucene-dev-archive@jakarta.apache.org Received: (qmail 24213 invoked by uid 500); 25 Sep 2004 19:12:21 -0000 Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Developers List" Reply-To: "Lucene Developers List" Delivered-To: mailing list lucene-dev@jakarta.apache.org Received: (qmail 24156 invoked by uid 99); 25 Sep 2004 19:12:16 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: domain of andi@osafoundation.org designates 204.152.186.98 as permitted sender) Received: from [204.152.186.98] (HELO kahuna.osafoundation.org) (204.152.186.98) by apache.org (qpsmtpd/0.28) with ESMTP; Sat, 25 Sep 2004 12:12:15 -0700 X-Envelope-From: andi@osafoundation.org Received: from localhost (kahuna.osafoundation.org [127.0.0.1]) by kahuna.osafoundation.org (8.12.8/8.12.8) with ESMTP id i8PJC3Bn021852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Sep 2004 12:12:10 -0700 Date: Sat, 25 Sep 2004 12:13:23 -0700 (PDT) From: Andi Vajda X-X-Sender: vajda@zoe.ovaltofu.org Reply-To: Andi Vajda To: lucene-dev@jakarta.apache.org Subject: DbDirectory and compound files Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.39 X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N The compound file storage implementation that became the default with Lucene 1.4 seems to not work so well with the Berkeley DB-based implementation of org.apache.lucene.store.Directory I submitted to the sandbox about 9 months ago. Even though this implementation, org.apache.lucene.store.db.DbDirectory, and its related classes are still exact as far as the interface defined by Directory and its related classes are concerned, there seems to be some apparently random failures that I'm thinking are related to implied flush semantics. I haven't looked into this any further yet as I'm wondering what sense using this compound file storage feature makes when using Berkeley DB storage since, in a way, Berkeley DB files are compound files themselves. The obvious workaround is to call IndexWriter.setUseCompoundFiles(False) but this workaround needs to be documented to be effective. So, my question: why is the compound file storage implemented in such an orthogonal to Directory way instead of just being another Directory implementation called FSCompoundFileDirectory ? Andi.. --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-dev-help@jakarta.apache.org