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:37:25 GMT
I think this would make sense... though, it'd be a shame if the
"simple case" becomes overbearing.  Maybe we can keep good defaults,
but use Version to allow us to change them.  So eg:

  new IndexWriter(new IndexWriter.Config(dir, analyzer, Version.LUCENE_29));

would be the "simple" case.

Mike

On Fri, Oct 2, 2009 at 6:54 PM, Michael Busch <buschmic@gmail.com> wrote:
> I was thinking lately about the large quantity of IndexWriter constructors
> and IndexReader open methods. I'm not sure if this has been proposed before,
> but what if we introduced new objects, e.g. IndexWriterConfig and
> IndexReaderConfig. They would contain getter/setter methods for all the
> different parameters the various constructors and open methods currently
> have. Then there would only be one IW constructor taking an
> IndexWriterConfig object as parameter and one open method in IR likewise.
> Then going forward we won't have to add/deprecate more ctors or open
> methods, we can then easily extend or deprecate getters/setters in the
> *Config classes.
>
>  Michael
>
> On 10/3/09 12:41 AM, Uwe Schindler 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