lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Janssen <jans...@parc.com>
Subject Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Date Fri, 17 Sep 2010 14:45:21 GMT
Simon Willnauer <simon.willnauer@googlemail.com> wrote:

> On Fri, Sep 17, 2010 at 8:14 PM, Bill Janssen <janssen@parc.com> wrote:
> > Simon Willnauer <simon.willnauer@googlemail.com> wrote:
> >
> >> Hey Bill,
> >> let me clarify what Version is used for since I think that caused
> >> little confusion.
> >
> > Thanks.
> >
> >> The Version constant was mainly introduced to help
> >> users with backwards compatibility and upgrading their codebase to a
> >> new version of lucene without breaking existing applications / indexes
> >> build with previous versions. For instance StandardAnalyzer preserves
> >> the positionIncrement in its StopFilter which was introduces in Lucene
> >> 2.9. If you use 2.4 and upgrade to 2.9 this change might break you app
> >> since you indexed with a 2.4 behavior. You phrasequeries might not
> >> work as expected anymore. If you don't have any upgrade issues or if
> >> you can simply reindex you might just use the latest version.
> >
> > That's what I'm trying to do.  But how?  LUCENE_CURRENT is deprecated!
> >
> > How about adding a constructor for StandardAnalyzer that takes no
> > parameters and is implicitly LUCENE_CURRENT?
> 
> We deprecated LUCENE_CURRENT for a good reason that is that folks will
> run into big trouble if they upgrade from X to X+n because behavior
> may change dramatically due to optimizations, bug fixes and useful
> features. If you blindly pass LUCENE_CURRENT you might end up with
> incompatible APIs in some cases (we do deploy "sophisticated backwards
> layers" like we did in CharTokenizer) or query analysis which will not
> work with you existing Version X index.

Yes, but that's not an issue if I don't *have* existing version X
indices, which I don't.

> What you should do is pick YOUR latest version manually and go through
> the changes once you upgrade. Write unittests for you API to make sure
> it does not break you code. Its worth the trouble!

Simon, this advice isn't helping.

I have unittests, and, yes, they are worth the trouble.  I always
re-index my collection if I change to a different version of Lucene.
So I'd like to make my choice of the value of
org.apache.lucene.util.Version automatically, using tools, instead of
choosing it manually, based on what version of Lucene the user has
installed, and without encoding a limited set of strings in my
application.

How do I do that?  More directly, is there any attribute or static
method somewhere in Lucene which will return a value of
org.apache.lucene.util.Version that corresponds to the version of the
code?  That's what I'm looking for.  Version.LUCENE_CURRENT looks good,
but it's deprecated.

Or, is there a method which will take a Lucene version, expressed as a
Package or perhaps even a string like "3.0.2", and return the
appropriate Version value?  If so, I could write my own code to retrieve
the Lucene version, then call that method to retrieve the Version value.

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message