lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Siraj Haider <si...@jobdiva.com>
Subject Re: WhitespaceAnalyzer and version
Date Tue, 13 Apr 2010 14:33:40 GMT
Hi Uwe,

On 4/13/2010 2:23 AM, Uwe Schindler wrote:
> As of Lucene 3.0, WhitespaceAnalyzer has not yet a Version ctor. It will come in 3.1,
when Lucene is changed to be Unicode 4.0 conform (3.0 and before is Unicode 3.0, which is
Java 1.4).
>
> QueryParser need the Version ctor for the handling of stop words. As WhiteSpace Analyzer
does not use StopFilter, there was no need for a version ctor. QueryParser will pass the version
not to the analyzer, it will use it solely for its own behavior. But you should use the same
version for QP and your Analyzer. If one of the components has no Version, there is no incompatible
change (in fact, Whitespace Analyzer was not changed). Please also read the document about
moving from Java 1.4 to Java 5/6 in the Lucene ZIP file (if you already used Java 5/6 with
older Lucene versions before, all is fine - reindexing may only required if you move your
JVM installation from 1.4 ->  5/6; independent from Lucene's version).
>
>    
We are using java 1.6, so that part is covered.
>> Another thing is, do we need to re-index if we want to supply
>> Version.LUCENE_CURRENT as the version? what are other implications?
>>      
> Yes! And please, please: Don't use Version.LUCENE_CURRENT (which is already deprecated
as of Lucene 2.9.2 and 3.0.1 as a warning). Use a specific version, so you will never need
to reindex until you change the version.
>
> To have backwards compatibility with existing indexes from pre-2.9 without reindexing
use LUCENE_24.
>    
We are using Lucene 2.9.2 now but planning to move to version 3 in near 
future.  I am a little confused about this version stuff and how you 
have to re-index if you want to use a newer version.  In past, all you 
had to do, is to add one document to index using new version and the 
index used to get converted to that format automatically, is it not the 
case now? If that is not the case, then this might be very difficult for 
us to handle because we have over 500+ indexes and re-indexing all of 
them is a huge task for us.

One more question, we use LUCENE_29 for now and in near future want to 
move to LUCENE_30.  Will the queryparsers/analyzers opened with 
LUCENE_30 be able to read indexes created by using LUCENE_29?
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>    
>> -----Original Message-----
>> From: Siraj Haider [mailto:siraj@jobdiva.com]
>> Sent: Monday, April 12, 2010 11:14 PM
>> To: java-user@lucene.apache.org
>> Subject: WhitespaceAnalyzer and version
>>
>> We are in the process of removing the deprecated api from our code to
>> move to version.  One of the deprecation is, the queryparser now
>> expects
>> a version parameter in the constructor.  I also have read somewhere
>> that
>> we should pass the same version to analyzer when indexing as wel as
>> when
>> searching.  We use WhitespaceAnalyzer and I am unable to find a
>> constructor with a version in it.
>>
>> Another thing is, do we need to re-index if we want to supply
>> Version.LUCENE_CURRENT as the version? what are other implications?
>>
>> thanks
>> -siraj
>>
>> ---------------------------------------------------------------------
>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message