On Wed, May 20, 2009 at 12:55 PM, Andi Vajda <va...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
