lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 00:13:21 GMT
I already started with removing deprecations in o.a.l.store and make FSDir
abstract. This package is finished, now I have to remove all these
open()/ctors using getDirectory().

Will post a patch tomorrow! Good night!

Uwe

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Saturday, October 03, 2009 1:33 AM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
> 
> Sigh.  The introduction of new but deprecated methods is silly.  Is
> there some simple automated way to catch/prevent these?
> 
> The proliferation of ctors/factory methods is a nightmare.
> 
> Part of the story with IndexReader.open is the switch to readOnly
> IndexReaders.  After the long back-compat discussion we settled on
> adding new ctors as the best way to make the change.
> 
> On deprecation of Version.LUCENE_29, that doesn't seem right.  In fact
> I don't think LUCENE_24 should be deprecated, either, since these
> constants are used by StandardAnalyzer to state compatibility that's
> "equivalent" to index format compability (from our last discussion).
> 
> I think deprecation by separate area makes sense?
> 
> Mike
> 
> On Fri, Oct 2, 2009 at 6:41 PM, Uwe Schindler <uwe@thetaphi.de> wrote:
> > When looking for press articles about the release of Lucene 2.9, I found
> the
> > following one from Bernd Fondermann
> > @ http://it-republik.de/jaxenter/artikel/Apache-Lucene-2.9-2594.html
> >
> > Translation with Google Translate:
> > ------------------------------------------------------------------------
> ----
> > Deprecated
> >
> > An index reader is created via the static open () factory method, of
> which
> > there were 2.4 in all nine. Five of them are now deprecated. In 2.9
> there
> > are now a total of 14 open-overloaded variants, with eight of them but
> they
> > are deprecated. This means that there are even some additions that have
> been
> > directly identified with introduction as deprecated - confusing.
> >
> > The constructor-Deprecation orgy goes for the standard Analyzer, one of
> the
> > key classes during indexing and querying further. This class has now no-
> less
> > constructor arguments over what might, perhaps, some downstream
> libraries
> > bring to stumble to instantiate their analyzer on a property, which
> contains
> > the class name dynamically. Instead, an object version must be given to
> set
> > for compatibility with 2.4 or 2.9. Both the VERSION_24 as well as the
> > VERSION_29 parameters are deprecated but themselves - very confusing!
> > VERSION_CURRENT is the only safe investment in the future, a value which
> we
> > certainly also as assignment in a zero-argument constructor would have
> > trusted.
> >
> > To write an index we need an index writer instance. Again, the majority
> of
> > the 19 possible constructors are about to be put to retire to.
> > ------------------------------------------------------------------------
> ----
> >
> > What was going wrong with the open() hell in IR? Very strange, I should
> have
> > looked better.
> >
> > By the way: How to proceed with deprecation removal? Case-by-case (e.g.
> > start with TS API, then these open() calls, then FSDirectory - to list
> the
> > ones I was involved) or some hyper-patch?
> >
> > By the way, here is my talk @ Hadoop GetTogether in Berlin:
> >
> > http://blog.isabel-drost.de/index.php/archives/category/events/apache-
> hadoop
> > -get-together-berlin
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-dev-help@lucene.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org



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


Mime
View raw message