From dev-return-13375-apmail-jackrabbit-dev-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Aug 15 13:14:15 2007 Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 43152 invoked from network); 15 Aug 2007 13:14:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Aug 2007 13:14:12 -0000 Received: (qmail 83281 invoked by uid 500); 15 Aug 2007 13:14:09 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 83248 invoked by uid 500); 15 Aug 2007 13:14:09 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 83239 invoked by uid 99); 15 Aug 2007 13:14:09 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2007 06:14:09 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [213.133.33.40] (HELO smtp.is.nl) (213.133.33.40) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2007 13:14:22 +0000 Received: from [213.133.51.241] (HELO hai01.hippo.local) by smtp.is.nl (CommuniGate Pro SMTP 5.0.10) with ESMTP id 21615306 for dev@jackrabbit.apache.org; Wed, 15 Aug 2007 15:13:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6619.12 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Re: improving the scalability in searching Date: Wed, 15 Aug 2007 15:13:44 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: improving the scalability in searching Thread-Index: AcffNiAJkB1By1ddTACnaIVhJaRFkAAB3rdg From: "Ard Schrijvers" To: X-Virus-Checked: Checked by ClamAV on apache.org > Christoph Kiehl wrote > There should never be an index where the old and the new=20 > format is mixed. Either=20 > you have an index without the new field, to which you will=20 > never add a document=20 > with the new field, or you have an index with the new field=20 > which means you can=20 > rely on the fact that all documents are in the new format and=20 > index your new doc=20 > with the new field. > If you have no index at all you start with a new index to=20 > which only documents=20 > with the new field will be added. There should be a flag set=20 > at startup for=20 > example in SearchIndex which indicates if an index is in the=20 > new or old format.=20 > This flag should be used by NodeIndexer and MatchAllScorer=20 > somehow to decide=20 > which strategy to use. > Hope I made my thoughts clear ;) not sure it's understandable. It is crystal clear: When you have old format, you stay in that format, = if you start with new index, you get the new format. Clear and = implementable IMO. I can give it a try and implement it unless somebody = else wants to do it? Regards Ard >=20 > Cheers, > Christoph >=20 >=20