Mailing-List: contact lucy-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: lucy-dev@incubator.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4CDC0A18.7090207@peknet.com>
Date: Thu, 11 Nov 2010 09:22:00 -0600
From: Peter Karman <peter@peknet.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: lucy-dev@incubator.apache.org
References: <20101110154934.GA17757@rectangular.com>
In-Reply-To: <20101110154934.GA17757@rectangular.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [lucy-dev] Index modernizer

Marvin Humphrey wrote on 11/10/2010 09:49 AM:
> Greets,
> 
> As the index format changes, we accumulate cruft in our codebase to support
> old indexes and old segments.  At some point, we need to purge such cruft and
> abandon support for old indexes.  But if you are a user, it's hard to know
> whether your index has old segments in it, and whether you can upgrade safely
> to a given version of the library.
> 

You're describing the back compat path for KS users switching to Lucy, yes?

> I'm torn as to where to implement this functionality.  Since it may be
> necessary to load custom classes, e.g. FieldType or Schema subclasses, that
> suggests a Cookbook/sample app which the user might modify.  On the other
> hand, if we are going to require that users run this app in order to upgrade
> -- and we will, sooner or later -- maybe there ought to be a core class,
> Lucy::Index::Modernizer...  Probably best to start with Cookbook/sample code
> which makes no public API promises, methinks...
> 

Yes. Maybe write the cookbook recipe for upgrading KS to Lucy, and then
we can see if it needs to be formalized into a part of the core?

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com