> I think AS is overkill for conveying configuration of IW/IR? Agree. > It's too cumbersome, I think, for something that ought to be simple. > I'd prefer a dedicated config class with strongly typed setters > exposed. Of all the "pure syntax" options so far I'd still prefer the > traditional "config object with setters". Builders are visually cleaner. But well, it's just my aestetical preference.
> Also, I don't think we should roll this out for all Lucene classes. I > think most classes do just fine accepting args to their ctor. EG > TermQuery simply takes Term to its ctor. It's obvious. > I do agree IW should not be in the business of brokering changes to > the settings of its sub-components (eg mergeFactor, maxMergeDocs). > You really should make such changes directly via your merge policy. Aaaand, you shouldn't do such changes after construction :) > But, then, I can also see it'd simplify our code to not have to deal > w/ such changes, reduce chance of subtle bugs, and it seems minor to > go and re-open your IndexWriter if you need to make a settings change? > (Hmm except in an NRT setting, because the reader pool would be reset; > really we need to get the reader pool separated from the IW instance). Even if recreating IW is costly, you don't change settings that often, isn't it? Mark: > Agreed we need to deal with - *but* I personally think it gets tricky. > Users should be able to flip compound on/off easily without dealing with > a mergepolicy IMO. And advanced users that set a mergepolicy shouldn't > have to deal with losing a compound setting they set with IW after > setting a new mergepolicy. Can't I have it both ways :) I don't understand why on earth compound setting is a property of MergePolicy. The question of which segments to merge is really orthogonal to the way you store these segments on disk. -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
