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

Reply via email to