lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@osafoundation.org>
Subject Re: Lucene's default settings & back compatibility
Date Wed, 20 May 2009 16:55:00 GMT

On Wed, 20 May 2009, Michael McCandless wrote:

> On Wed, May 20, 2009 at 11:57 AM, Yonik Seeley
> <yonik@lucidimagination.com> wrote:
>> On Wed, May 20, 2009 at 11:46 AM, Mark Miller <markrmiller@gmail.com> wrote:
>>> Marvin Humphrey wrote:
>>>>
>>>> Yeesh, that's evil.  :(
>>>>
>>>> It will be sweet, sweet justice if one of your own projects gets infected
>>>> by
>>>> the kind of action-at-a-distance bug you're so blithely unconcerned about
>>>
>>> Heh. Thats a bit over the top. It is evil stuff, but its much less evil in
>>> this very contained instance than the general case. Much less.
>>>
>>> But still a bit evil with the potential to grow. I'm not anymore of a fan of
>>> passing a config to each class though. But I guess from a design point
>>> of view, it does feel a little less evil.
>>
>> Agree.
>>
>> But passing settings around doesn't solve the problem.  Example:  New
>> settings may be chosen by an application for an IndexSearcher that's
>> incompatible with a custom older Query/Weight/Scorer.  There's really
>> no getting around that problem.  I think the static helps solve
>> drop-in compat for a complete working application.  Good components
>> should only be checking the static, not setting it.
>
> Also, this static setting simply tells Lucene how to default settings.
>
> A component/app can still be explicit when creating classes.  EG when
> opening an IndexReader, if one always passes in the readOnly arg then
> the static "actsAsVersion" would not be used.

I've been watching this thread with interest with my opinion swaying back 
and forth.

This last comment, though, pushes me to favor the settings class idea 
because that idea came with the promise of eliminating the combinatorial 
explosion of contructor and method overloads.

In addition, I very much like the idea of having one place list all the 
coherent configuration choices one can make. No, CHANGES.txt is not it. 
While it's interesting reading, it reads like a blog. It doesn't tie 
sensible settings together. It only gives a differential and chronological 
view of changes.

Having version-specific settings classes is a really neat place to list all 
possible settings in one place with sensible and coherent values for a 
version. The same idea could be used for other things than version by the 
way. It could help in picking one side of a configuration trade off over 
another.

For example:
    - a settings for favoring speed of updates over speed of queries if that
      makes sense
    - a settings for favoring index size over indexing speed
    ... and so on.

I don't see why this has to be limited just to Lucene version backwards
compatibility. Oh, and about that: I think we've reached the breaking point 
about backwards compatibility support a while ago. I recently hit a bug in 
my code where a commit() call was missing. Before 2.4, flushing the index 
committed it. Starting with 2.4, this is no longer the case. Yes, this is 
documented and that helped me fix the bug really quickly but backwards 
compatible it is not. My point here is that we've promised too much 
backwards compatibility for too long and it's been getting too hard to 
deliver that promise now.

Andi..

Mime
View raw message