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 <u...@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: u...@thetaphi.de > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
