Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of glen.newton@gmail.com
 designates 209.85.211.183 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;
        b=xiCnXbQJr/tIBIF52JYPNbtjxMqsZghhbR+Wuxq2AKQtUPUq/AdbiHF+zH5bocwYWk
         uPTqVCUHDcugTQ44av7QUd64eaK9rt4SgvObtgJaglPEVdUsjCzNCfS+yOt8PQwbqp4B
         MFKeTCSQmC6fqPlNuFKx5SypwHrAGliDDCF9c=
MIME-Version: 1.0
In-Reply-To: <4B032813.2080201@gmail.com>
References: <7236BE28C65B4239AB6D55B6F8C64A70@VEGA>
	 <5e76f3840911171435p2a763eb5lbfde1e7071a34db4@mail.gmail.com>
	 <4B032813.2080201@gmail.com>
Date: Tue, 17 Nov 2009 22:53:01 -0500
Message-ID: <5e76f3840911171953w55a9688bk28efbae400cf6020@mail.gmail.com>
Subject: Re: Lucene Java 3.0.0 RC1 now available for testing
From: Glen Newton <glen.newton@gmail.com>
To: java-user@lucene.apache.org
Content-Type: text/plain; charset=UTF-8

I understand the reasons, but - if I may ask so late in the game - was
this the best way to do this?

>From a user (developer) perspective, this is an implementation issue.
Couldn't this have been done behind the scenes, so that when I asked
for Field.Index.ANALYZED  && Field.Store.COMPRESS, instead of what
previously happened (and was variously problematic), two fields were
transparently created, one being binary compressed stored and the
other being indexed only? The Field API could hide all of this
complexity, using one underlying Field when I use Field.getString()
(compressed stored one), using the other when I use Field.setBoost()
(the indexed one) and both when I call Field.setValue(). This might
have less impact on developers and be less disruptive on API changes.
Oh, some naming convention could handle the underlying Fields.

A little complicated I agree.

Again, apologies to those who worked hard on these changes: my fault
for not noticing this sooner (I hadn't started moving my code to 2.9
from 2.4 so I hadn't read the deprecation signs).

thanks,

Glen


2009/11/17 Mark Miller <markrmiller@gmail.com>:
> Here is some of the history:
>
> https://issues.apache.org/jira/browse/LUCENE-652
> https://issues.apache.org/jira/browse/LUCENE-1960
>
> Glen Newton wrote:
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
>
>
>
> ---------------------------------------------------------------------
> 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