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 Wed, 20 May 2009 19:10:49 GMT
On Wed, May 20, 2009 at 12:55 PM, Andi Vajda <vajda@osafoundation.org> wrote:

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

So have I!

> 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 thing is... the number of settings will be large over time, and so
we'll need a hierarchy of classes, or we fallback to Properties w/ the
hierarchy encoded in the string, but then you have a weakly typed API,
and you lose the self-documenting (like Grant observed).

Ie, in theory I love the idea of Settings, but in practice, as I start
to think about the realities of implementing it, I realize it's gonna
be a big challenge to solve it well.  This goes waaay beyond resolving
the back-compat vs new users conflict we have today.

Pushing to the way future, I'm also not convinced it's great that I
have to go to two places (IndexWriter and its *Settings counterpart)
to manage my "IndexWriter".

I think the idea can work, but I'm realizing it's a huuuge project (vs
actsAsVersion which is quite simple).

> 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.

Right -- Solr is discussing this now, too.  I think this would be
useful.

> I don't see why this has to be limited just to Lucene version backwards
> compatibility.

I think we should do "actsAsVersion" today, solely to resolve the
back-compat vs new users conflict, and continue to explore/discuss
Settings for these other reasons.

> 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.

Hmm -- I think we should have had flush() just call commit().

> 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.

I think it's high time we release 3.0 then!

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