lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Willnauer <>
Subject Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Date Fri, 17 Sep 2010 19:08:12 GMT
On Fri, Sep 17, 2010 at 8:14 PM, Bill Janssen <> wrote:
> Simon Willnauer <> 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.

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!

>> Some usecases might require somewhat "buggy" behavior which has been
>> fixed in various places in lucene but must be maintained because of
>> backwards compatibility this is also done by Version.
> Sure.
>> If a certain
>> class like IndexWriter / IndexReader have maintained compatibility
>> without a Version constant so there is no need to pass it to them. You
>> will be implicitly on the latest version.
> Good.
> Bill
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message