lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: Lucene Java 3.0.0 RC1 now available for testing
Date Wed, 18 Nov 2009 05:20:31 GMT
Well, I think some people will be for hiding complexity, while others will be for being in
control and having transparency.  Think how surprised one would be to find 1 extra field in
his index, say when looking at their index with Luke. :)
 Otis
--
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  && 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/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 :
> >>
> >>> 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


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


Mime
View raw message