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 Fri, 02 Oct 2009 23:45:10 GMT
> I like Earwin's version more. A builder is very flexible, because you can
> concat all your properties (like StringBuilder works with its append
> method
> returning itself) and create the instance at the end.

This is a really cool example of this builder pattern:

http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/
common/collect/MapMaker.html


> > -----Original Message-----
> > From: Michael McCandless [mailto:lucene@mikemccandless.com]
> > Sent: Saturday, October 03, 2009 1:37 AM
> > To: java-dev@lucene.apache.org
> > Subject: Re: Lucene 2.9 and deprecated IR.open() methods
> >
> > 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
> 
> 
> 
> ---------------------------------------------------------------------
> 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