On Thu, Feb 18, 2010 at 1:27 PM, Alexander Klimetschek <[email protected]> wrote: > On Thu, Feb 18, 2010 at 10:37, Ard Schrijvers <[email protected]> > 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 Ard > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
