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:content-transfer-encoding;
        b=Z5rdnBxvS4Jm8sCdaQFyQff/9rsSbhd0JIgzyiSAD8SFS+U7vXUiCHu9SVPCVVUxSb
         GhR45VNfk5Qn7MthKYLYwHW1ry6jqPqLNSosKl+EMqr7J+K7lZk5+Z8tvX4oGTDHIi9r
         11VP3PfyZYO4DroUypQcntWRyQXuSxpAA11mY=
MIME-Version: 1.0
In-Reply-To: <342825.42950.qm@web50310.mail.re2.yahoo.com>
References: <7236BE28C65B4239AB6D55B6F8C64A70@VEGA>
	 <5e76f3840911171435p2a763eb5lbfde1e7071a34db4@mail.gmail.com>
	 <4B032813.2080201@gmail.com>
	 <5e76f3840911171953w55a9688bk28efbae400cf6020@mail.gmail.com>
	 <342825.42950.qm@web50310.mail.re2.yahoo.com>
Date: Wed, 18 Nov 2009 09:24:29 -0500
Message-ID: <5e76f3840911180624u7b966c00teb389eed1dcbc7b9@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
Content-Transfer-Encoding: quoted-printable

Yes, I would agree with you on the surprise aspect. :-)

But you suggest hiding complexity, and being in control and having
transparency are mutually exclusive, which isn't necesarily the case.

I think I can live with the decisions made. :-)
If I can think of a viable and complete alternative, I'll run it by
the community.

thanks,
Glen

2009/11/18 Otis Gospodnetic <otis_gospodnetic@yahoo.com>:
> Well, I think some people will be for hiding complexity, while others wil=
l be for being in control and having transparency. =C2=A0Think how surprise=
d one would be to find 1 extra field in his index, say when looking at thei=
r index with Luke. :)
> =C2=A0Otis
> --
> Sematext is hiring -- http://sematext.com/about/jobs.html?mls
> Lucene, Solr, Nutch, Katta, Hadoop, HBase, UIMA, NLP, NER, IR
>
>
>
> ----- Original Message ----
>> From: Glen Newton <glen.newton@gmail.com>
>> To: java-user@lucene.apache.org
>> Sent: Tue, November 17, 2009 10:53:01 PM
>> Subject: Re: Lucene Java 3.0.0 RC1 now available for testing
>>
>> 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 =C2=A0&& 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 :
>> > 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/chang=
es/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 :
>> >>
>> >>> Hello Lucene users,
>> >>>
>> >>>
>> >>>
>> >>> On behalf of the Lucene dev community (a growing community far large=
r than
>> >>> just the committers) I would like to announce the first release cand=
idate
>> >>> for Lucene Java 3.0.
>> >>>
>> >>>
>> >>>
>> >>> Please download and check it out - take it for a spin and kick the t=
ires. 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 deprecat=
ion
>> >>> warnings in your code base to be able to recompile against this vers=
ion.
>> >>>
>> >>>
>> >>>
>> >>> This is the first Lucene release with Java 5 as a minimum requiremen=
t. 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 u=
sers 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 L=
ucene
>> >>> 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. Luce=
ne 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 decompres=
sed and
>> >>> converted to Field.Store.YES. Because of this, indexes with compress=
ed
>> >>> fields can suddenly get larger.
>> >>>
>> >>>
>> >>>
>> >>> While we generally try and maintain full backwards compatibility bet=
ween
>> >>> major versions, Lucene 3.0 has some minor breaks, mostly related to
>> >>> deprecation removal, pointed out in the 'Changes in backwards compat=
ibility
>> >>> policy' section of CHANGES.txt. Notable are:
>> >>>
>> >>>
>> >>>
>> >>> - IndexReader.open(Directory) now opens in read-only mode per defaul=
t (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 en=
force
>> >>> the decorator pattern.
>> >>>
>> >>> - If you interrupt an IndexWriter merge thread, IndexWriter now thro=
ws an
>> >>> unchecked ThreadInterruptedException that extends RuntimeException a=
nd
>> >>> clears the interrupt status.
>> >>>
>> >>>
>> >>>
>> >>> Also, remember that this is a release candidate, and not the final L=
ucene
>> >>> 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/c=
hanges/C
>> >>> hanges.html
>> >>>
>> >>>
>> >>>
>> >>> Text version:
>> >>>
>> >>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-rc1/c=
hanges/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/c=
hanges/C
>> >>> ontrib-Changes.html
>> >>>
>> >>>
>> >>>
>> >>> Text version:
>> >>>
>> >>> http://people.apache.org/~uschindler/staging-area/lucene-3.0.0-rc1/c=
hanges/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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>
>


--=20

-

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