Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates
 207.126.148.87 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <697f8381002180137h62b40eb9rf835a48651b94ac5@mail.gmail.com>
References: <697f8381002170748kdfbe59q4b5fd8ad0b7ba239@mail.gmail.com>
	 <91f3b2651002170815m53e4c162ubf608121d2860eb2@mail.gmail.com>
	 <697f8381002180135v2771042bkbfebe37417f69884@mail.gmail.com>
	 <697f8381002180137h62b40eb9rf835a48651b94ac5@mail.gmail.com>
Date: Thu, 18 Feb 2010 13:27:14 +0100
Message-ID: <c3ac3bad1002180427n532f4a70tc5f7de6d9719717e@mail.gmail.com>
Subject: Re: [jr3] Restructure Lucene indexing & make use of Lucene 2.9
	features
From: Alexander Klimetschek <aklimets@day.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Feb 18, 2010 at 10:37, Ard Schrijvers <a.schrijvers@onehippo.com> wrote:
> Addon: So my improvement would be to suggest to index every unique jcr
> fieldname in a unique lucene field, and do not prefix values as
> currently is being done. This makes lots of the lucene classes and
> queries in jr easier or redundant

+1

And as Felix noted, this is "just" an internal improvement to the
Lucene search index and can be done quite early in 2.x. The only
question is the migration of indexes. This could be done by still
supporting old-style indexes (for 2.x releases), but when a new index
is created, the newer variant is chosen. Existing repositories that
upgrade could then chose, ie. delete and re-index to get the new
structure.

If this makes the implementation too difficult, we could simply offer
a different SearchIndex implementation, so one can chose via the
configuration.

Regards,
Alex

-- 
Alexander Klimetschek
alexander.klimetschek@day.com