jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ard Schrijvers <a.schrijv...@onehippo.com>
Subject Re: [jr3] Restructure Lucene indexing & make use of Lucene 2.9 features
Date Thu, 18 Feb 2010 13:07:22 GMT
On Thu, Feb 18, 2010 at 1:27 PM, Alexander Klimetschek <aklimets@day.com> wrote:
> 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 we do this, I would also like to move to lucene 2.9, which is
incompatible, even in API with older version. I really think backward
support for existing indexes would be too much pain: people should be
able to reindex, this would solve the old style stuff. Wouldn't it be
reasonable to have people re-index their contents if they want to move
to the latest repository with a new lucene 2.9 version which is by
itself incompatible with older versions (though not sure whether it
can handle older existing indexes).

> If this makes the implementation too difficult, we could simply offer

I am having a headache already, so I think yes :-)

> a different SearchIndex implementation, so one can chose via the
> configuration.

would be easier. Unfortunately, we would still have all the 'old'
classes being redundant in the new version in the core...we though
could move them to some package


> Regards,
> Alex
> --
> Alexander Klimetschek
> alexander.klimetschek@day.com

View raw message