Hmm... I think we should still allow package private specification of the indexing chain?
Ok, I'll add it back.
I preferred not to (it's not just setAnalyzer, but also MS, Similarity and IndexDeletionPolicy). I specifically documented on each what happens if one passes null. I think it's better service - you're not expected to pass null, and so if you do, instead of throwing an exception, we revert to default. I thought at some point to add a restoreDefaults() method, but then realized that doing new IWC() is not that expensive ...
I think - if someone uses IWC but receives any of those settings from the outside, instead of asking him to always check for null, we tell him "pass null, we revert to default" ...
In IWC we call it "scheduler"
Woops, fixed that !
Why can't MergePolicy also live in IWC?
I've commented on it in this issue - MP requires an IW instance to be passed to its ctor.(see my comment from 04/Mar/10 09:28 PM).
IW.messageState will have a space before each of its entries
IWC.toString() includes '\n' between settings. I thought it'd be more readable that way because otherwise it'd be a long line. The output for me looks like that:
IW 0 [main]: dir=org.apache.lucene.store.RAMDirectory@2ca22ca2 mergePolicy=org.apache.lucene.index.LogByteSizeMergePolicy@6ca06ca index= version=3.1-dev config=matchVersion=LUCENE_31
Perhaps I'll print "config=\n" so that all config parameters start on the new line, and not all but the first. Is that acceptable, or you still prefer all to be on one line, space separated?
Need small jdoc for the new IW ctor
I'll add that. That one slipped .
Should we disallow all setters on IWC after it's been consumed by an IW?
I've thought about all the options that you raise, and decided to keep the situation as-is, to let others also comment on that. So I'm glad you commented .
- I've documented on IW.getConfig() that setting anything on the returned object has no effect on IW instance, and if one needs to do it, one should re-instantiate IW.
- I also thought to turn off setters (setting IWC to read-only by IW), but then someone won't be able to reuse an IWC
- Removing the fields from IW is not good, because then someone could really call getConfig().setMaxBufferedDocs and that will affect IW, unlike what the comment says. If we want to really keep everything in IWC, we need to clone on ctor and getConfig() time. Seems a waste to me.
I think I'll just clone the incoming IWC on IW and leave the rest as-is?