lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Fri, 02 Oct 2009 23:33:06 GMT
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


Mime
View raw message