On Tue, May 19, 2009 at 4:34 AM, mark harwood <markharw...@yahoo.co.uk> wrote: > >>When you create IndexReader, IndexWriter and others, you must pass in a >>Settings >> instance. > > I think this would also help solve the steady growth of constructor > variations (18 in 2.4's IndexWriter vs 3 in Lucene 1.9).
Right. So for example the transition of IndexWriter from autoCommit=true to autoCommit=false would have been quite a bit cleaner if we had *Settings classes. We would have left SettingsMatching23 with autoCommit=true, and SettingsMatching24/CurrentVersionSettings would set autoCommit=false, without doubling IndexWriter's ctors. Though we'd need clear guidelines on things that become settings vs things that remain args to ctors, or set/gets. Should IndexDeletionPolicy be a setting? (I think so? It's shared b/w IndexWriter & IndexReader doing "write" ops). Maybe MergePolicy/Scheduler should be a setting, so we have freedom to improve the default with time. The Analyzer instance? The Similarity instance (which is used both during indexing & searching)? On IndexWriter's MaxFieldLength I'm torn on -- it was graduated to a ctor arg explicitly so you're forced to choose to have your fields truncated or not (since it was a common hidden trap). Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
