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: u...@thetaphi.de

-----Original Message-----
From: Glen Newton [mailto:glen.new...@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 <u...@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: u...@thetaphi.de







--

-

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



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

Reply via email to