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.new...@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: u...@thetaphi.de > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> > >> > >> > >> > > > > > > -- > > - Mark > > > > http://www.lucidimagination.com > > > > > > > > > > --------------------------------------------------------------------- > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
