Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of jmuguruza@gmail.com designates
 209.85.220.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Njhagoyapc6AUHx8GIep44QtWLn6zwvEHLggMamPDFgP3E1CnArW5ND9qOUQ0oN4pp
         22P/VFV7grim+jny0MraaWmTefnmJITDyiZziE6vVL470G6I5BJj3IRKRgY2oEJ5sQIX
         MRJ28R+sPhaVIGjOb9m+3XoYo+fEUfQwTVqSM=
MIME-Version: 1.0
In-Reply-To: <8f0ad1f31002180635va25d3dh13a69f146c97370a@mail.gmail.com>
References: <f071061b1002160247n60b12fbdk5917f43ac478b6fa@mail.gmail.com>
	 <8c4e68611002180342w642f44b2ud18d7dc7842a1d1@mail.gmail.com>
	 <8f0ad1f31002180520s11b53ee0o8e8a8ead75597cfc@mail.gmail.com>
	 <8c4e68611002180624p13656818u9c37df8ea22f1a29@mail.gmail.com>
	 <8f0ad1f31002180635va25d3dh13a69f146c97370a@mail.gmail.com>
Date: Thu, 18 Feb 2010 16:00:32 +0100
Message-ID: <f071061b1002180700v62c8c689w344a5ae3ff50e646@mail.gmail.com>
Subject: Re: questions on upgrading to 3.0: Version.LUCENE_* and
	Field.setOmitNorms()
From: jm <jmuguruza@gmail.com>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks for the replies Ian and Robert. In my case, I am in a bit of a
uneasy position, cannot reindex, original docs are gone...

What would you recommend? I have to choose one value, and some
customers started using our system with lucene 2.3, others with lucene
2.4 and others with 2.9.
My usage of problematic classes are (in the older code):

public final class CustomStopAnalyzer extends Analyzer {
    private Set stopWords;
    public CustomStopAnalyzer() {
        this.stopWords =3D
CustomStopFilter.makeStopSet(StopWordCustomList.getStopwords());
    }
    public TokenStream tokenStream(String fieldName, Reader reader) {
        return new CustomStopFilter(new
LowerCaseLetterNumberTokenizer(reader), stopWords);
    }
    public static CustomStopAnalyzer getTestCustomAnalyzer(String lang) {
        CustomStopAnalyzer ca =3D new CustomStopAnalyzer(lang);
        return ca;
    }
}

public class CustomStopFilter extends TokenFilter {...}
public final class LowerCaseLetterNumberTokenizer extends LetterTokenizer {
    public LowerCaseLetterNumberTokenizer(Reader in) {
        super(in);
    }

    protected boolean isTokenChar(char c) {
        return Character.isLetterOrDigit(c);
    }

    protected char normalize(char c) {
        return Character.toLowerCase(c);
    }
}

javi

On Thu, Feb 18, 2010 at 3:35 PM, Robert Muir <rcmuir@gmail.com> wrote:
> yes, if you use LUCENE_CURRENT, you may have to reindex (if any
> analyzers/tokenizers you are using have changed).
>
> if you use an actual version (for example LUCENE_30), you can upgrade you=
r
> jar file to say a future 3.1 jar without reindexing, then later at your
> leisure (after testing/qa whatever you want), you can bump your version t=
o
> LUCENE_31 and reindex.
>
> On Thu, Feb 18, 2010 at 9:24 AM, Ian Lea <ian.lea@gmail.com> wrote:
>
>> But typically you wouldn't need to reindex, would you? =A0From the 3.0
>> javadocs for LUCENE_CURRENT:
>>
>> WARNING: if you use this setting, and then upgrade to a newer release
>> of Lucene, sizable changes may happen. If precise back compatibility
>> is important then you should instead explicitly specify an actual
>> version.
>>
>> I read this as meaning that it is safe to use it unless you want
>> precise back compatibility and are prepared to accept the risk that
>> you may have to reindex. =A0When upgrading my code and indexes to 3.0
>> I've used LUCENE_CURRENT and haven't reindexed, and haven't noticed
>> any problems.
>>
>>
>> --
>> Ian.
>>
>>
>>
>> On Thu, Feb 18, 2010 at 1:20 PM, Robert Muir <rcmuir@gmail.com> wrote:
>> > Only use LUCENE_CURRENT if you do not care about backwards compatibili=
ty
>> at
>> > all: e.g. you are perfectly happy re-indexing all data when you upgrad=
e
>> the
>> > lucene jar file in future.
>> >
>> > its not about relying on quirks in previous versions of lucene, its ab=
out
>> > being compatible with changes in future versions, you set it to LUCENE=
_30
>> or
>> > whatever so that you can upgrade to 3.1 jar, without reindexing.
>> >
>> > On Thu, Feb 18, 2010 at 6:42 AM, Ian Lea <ian.lea@gmail.com> wrote:
>> >
>> >>
>> >> Unless you are relying on quirks in particular versions of lucene
>> >> setting it to LUCENE_CURRENT is probably best.
>> >>
>> >>
>> > --
>> > Robert Muir
>> > rcmuir@gmail.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
>>
>
>
> --
> Robert Muir
> rcmuir@gmail.com
>

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