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