lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Lu <chris...@gmail.com>
Subject Re: Lucene Java 3.0.0 RC1 now available for testing
Date Wed, 18 Nov 2009 00:06:03 GMT
So will I need to use 2 fields, one filed is analyzed and the other 
field is binary, to replace one compressed fields previously?

--
Chris Lu
-------------------------
Instant Scalable Full-Text Search On Any Database/Application
site: http://www.dbsight.net
demo: http://search.dbsight.com
Lucene Database Search in 3 minutes: http://wiki.dbsight.com/index.php?title=Create_Lucene_Database_Search_in_3_minutes
DBSight customer, a shopping comparison site, (anonymous per request) got 2.6 Million Euro
funding!



Uwe Schindler wrote:
> Because you can do the compression yourself by just adding a binary stored
> field with the compressed content. And then you can use any algorithm, even
> bz2 or whatever.
>
> The problem is that the compressed fields made lot's of problems and special
> cases during merging, because they were always decompressed, recompressed
> and so on. If you need compressed  fields, do it yourself, there is a new
> class since 2.9.0 called CompressionUtils that can compress strings or
> byte[] to compressed byte[]. Add the result to your index as binary stored
> field and voila.
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>   
>> -----Original Message-----
>> From: Glen Newton [mailto:glen.newton@gmail.com]
>> Sent: Tuesday, November 17, 2009 11:36 PM
>> To: java-user@lucene.apache.org
>> Subject: Re: Lucene Java 3.0.0 RC1 now available for testing
>>
>> Could someone send me where the rationale for the removal of
>> COMPRESSED fields is? I've looked at
>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-
>> rc1/changes/Changes.html#3.0.0.changes_in_runtime_behavior
>> but it is a little light on the 'why' of this change.
>>
>> My fault - of course - for not paying attention.
>>
>> thanks,
>> Glen
>>
>> 2009/11/17 Uwe Schindler <uwe@thetaphi.de>:
>>     
>>> Hello Lucene users,
>>>
>>>
>>>
>>> On behalf of the Lucene dev community (a growing community far larger
>>>       
>> than
>>     
>>> just the committers) I would like to announce the first release
>>>       
>> candidate
>>     
>>> for Lucene Java 3.0.
>>>
>>>
>>>
>>> Please download and check it out - take it for a spin and kick the
>>>       
>> tires. If
>>     
>>> all goes well, we hope to release the final version of Lucene 3.0 in a
>>> little over a week.
>>>
>>>
>>>
>>> The new version is mostly a cleanup release without any new features.
>>>       
>> All
>>     
>>> deprecations targeted to be removed in version 3.0 were removed. If you
>>>       
>> are
>>     
>>> upgrading from version 2.9.1 of Lucene, you have to fix all deprecation
>>> warnings in your code base to be able to recompile against this version.
>>>
>>>
>>>
>>> This is the first Lucene release with Java 5 as a minimum requirement.
>>>       
>> The
>>     
>>> API was cleaned up to make use of Java 5's generics, varargs, enums, and
>>> autoboxing. New users of Lucene are advised to use this version for new
>>> developments, because it has a clean, type safe new API. Upgrading users
>>>       
>> can
>>     
>>> now remove unnecessary casts and add generics to their code, too. If you
>>> have not upgraded your installation to Java 5, please read the file
>>> JRE_VERSION_MIGRATION.txt (please note that this is not related to
>>>       
>> Lucene
>>     
>>> 3.0, it will also happen with any previous release when you upgrade your
>>> Java environment).
>>>
>>>
>>>
>>> Lucene 3.0 has some changes regarding compressed fields: 2.9 already
>>> deprecated compressed fields; support for them was removed now. Lucene
>>>       
>> 3.0
>>     
>>> is still able to read indexes with compressed fields, but as soon as
>>>       
>> merges
>>     
>>> occur or the index is optimized, all compressed fields are decompressed
>>>       
>> and
>>     
>>> converted to Field.Store.YES. Because of this, indexes with compressed
>>> fields can suddenly get larger.
>>>
>>>
>>>
>>> While we generally try and maintain full backwards compatibility between
>>> major versions, Lucene 3.0 has some minor breaks, mostly related to
>>> deprecation removal, pointed out in the 'Changes in backwards
>>>       
>> compatibility
>>     
>>> policy' section of CHANGES.txt. Notable are:
>>>
>>>
>>>
>>> - IndexReader.open(Directory) now opens in read-only mode per default
>>>       
>> (this
>>     
>>> method was deprecated because of that in 2.9). The same occurs to
>>> IndexSearcher.
>>>
>>> - Already started in 2.9, core TokenStreams are now made final to
>>>       
>> enforce
>>     
>>> the decorator pattern.
>>>
>>> - If you interrupt an IndexWriter merge thread, IndexWriter now throws
>>>       
>> an
>>     
>>> unchecked ThreadInterruptedException that extends RuntimeException and
>>> clears the interrupt status.
>>>
>>>
>>>
>>> Also, remember that this is a release candidate, and not the final
>>>       
>> Lucene
>>     
>>> 3.0 release.
>>>
>>>
>>>
>>> You can find the full list of changes here:
>>>
>>>
>>>
>>> HTML version:
>>>
>>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-
>>>       
>> rc1/changes/C
>>     
>>> hanges.html
>>>
>>>
>>>
>>> Text version:
>>>
>>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-
>>>       
>> rc1/changes/C
>>     
>>> hanges.txt
>>>
>>>
>>>
>>> Changes have also occurred in Lucene's contrib area:
>>>
>>>
>>>
>>> HTML version:
>>>
>>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-
>>>       
>> rc1/changes/C
>>     
>>> ontrib-Changes.html
>>>
>>>
>>>
>>> Text version:
>>>
>>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-
>>>       
>> rc1/changes/C
>>     
>>> ontrib-Changes.txt
>>>
>>>
>>>
>>> Download release candidate 1 here:
>>>
>>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-rc1/
>>>
>>>
>>>
>>> Be sure to report back with any issues you find! Look especially for
>>>       
>> faults
>>     
>>> in generification of public APIs (like missing wildcards,...).
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Uwe Schindler
>>>
>>>
>>>
>>> -----
>>>
>>> Uwe Schindler
>>>
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>>
>>> http://www.thetaphi.de
>>>
>>> eMail: uwe@thetaphi.de
>>>
>>>
>>>
>>>
>>>
>>>
>>>       
>>
>> --
>>
>> -
>>
>> ---------------------------------------------------------------------
>> 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