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's default settings & back compatibility
Date Tue, 19 May 2009 11:51:53 GMT
On Tue, May 19, 2009 at 4:34 AM, mark harwood <markharw00d@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message