lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Lea <ian....@gmail.com>
Subject Re: recommended way to identify a version to pass to StandardAnalyzer constructor?
Date Tue, 21 Sep 2010 15:12:11 GMT
+1 for a static method to get the appropriate value of Version.


--
Ian.


On Sun, Sep 19, 2010 at 11:21 PM, Bill Janssen <janssen@parc.com> wrote:
> Simon Willnauer <simon.willnauer@googlemail.com> wrote:
>
>> On Fri, Sep 17, 2010 at 11:45 PM, Bill Janssen <janssen@parc.com> wrote:
>> > 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.
>> Well then why don't you just use the Version.LUCENE_30 and assign it
>> to some static final variable like:
>> class MyConstants { public final Version LUCENE_VERSION =
>> Version.LUCENE_30; } and use it everywhere?!
>
> Because that will break if what my users have installed is Lucene 2.9.3.
>
>> We moved away from LUCENE_CURRENT for the reasons I mentioned - if
>> that made you aware of what could happen our plans worked out.
>
> I was already aware, but I do appreciate you folks thinking of your
> users.  I just wish those plans had been thought out a bit more.  But
> that's software development, isn't it :-?
>
>> Version of the code? I don't understand.. the max value of Version is
>> your lucene version, does that help?!
>
> Yep.  That's what I'm using:
>
>    # we'd like to make this the latest Version that this Lucene knows
>    # about, because that's what the index will be using, but using
>    # Version.LUCENE_CURRENT is deprecated, and there's no API to map
>    # from the Lucene version string to the Version value for that
>    # string.  To make things worse, the 2.9 code doesn't support the
>    # values() method, and Version doesn't implement Comparable, so I
>    # can't just use max().  So, this complexity:
>
>    def _order(v1, v2):
>        if v1.equals(v2):
>            return 0
>        if v1.onOrAfter(v2):
>            return 1
>        else:
>            return -1
>    _values = sorted([getattr(Version, x) for x in Version.__dict__
>                      if (x.startswith("LUCENE") and (x != "LUCENE_CURRENT"))],
>                     cmp=_order)
>    _indexversion = _values[-1]
>    del _order, _values
>
>
>> > 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.
>>
>> org.apache.lucene.util.Constants#LUCENE_MAIN_VERSION
>> org.apache.lucene.util.Constants#LUCENE_VERSION
>
> Yes, those are the strings I would use.  Now, how do I map from that
> string to an appropriate value of Version?  I think Version should grow
> a static method for doing that:
>
>  Version theVersion = Version.valueOf(Constants.LUCENE_MAIN_VERSION);
>
> Thanks,
>
> Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>

---------------------------------------------------------------------
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