[
https://issues.apache.org/jira/browse/LUCENE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842015#action_12842015
]
Michael McCandless commented on LUCENE-2294:
--------------------------------------------
Ha, I see TODO 4.0 comments now. Sheesh ;)
Patch looks great Shai!
A few comments:
* Hmm... I think we should still allow package private specification
of the indexing chain? Not long ago Michael B. explicitly opened
this up (while keeping it package private). I think for
way-expert users we should keep it extensible?
* For IWC.setAnalyzer(null), instead of silently swapping in
WhitespaceAnalyzer, can we throw IllegalArgE?
* Should we disallow all setters on IWC after it's been consumed by
an IW? (Though one may want to re-use to make another IW).
Or... make it very clear that IW fully consumes the IWC on
creation and never again looks at it...? (OK, I do see this in
IW.getConfig and IWC). Should IW just clone the IWC and reference
it internally, instead of copying to private fields? Or... IW
marks the IWC readOnly (and setters on it then fail), and you must
clone it if you will re-use?
* In IWC we call it "scheduler" but seems like we should keep the
name "mergeScheduler"? (And in toString, too).
* Why can't MergePolicy also live in IWC? Seems odd to move
MergeScheduler to it but not MP. (And deprecate set/getMP in IW)
* Nit-picky, but, IW.messageState will have a space before each of
its entries but then IWC's entries have no space -- looks not so
nice on enabling infoStream?
* Need small jdoc for the new IW ctor
> Create IndexWriterConfiguration and store all of IW configuration there
> -----------------------------------------------------------------------
>
> Key: LUCENE-2294
> URL: https://issues.apache.org/jira/browse/LUCENE-2294
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Reporter: Shai Erera
> Fix For: 3.1
>
> Attachments: LUCENE-2294.patch
>
>
> I would like to factor out of all IW configuration parameters into a single
> configuration class, which I propose to name IndexWriterConfiguration (or
> IndexWriterConfig). I want to store there almost everything besides the
> Directory, and to reduce all the ctors down to one: IndexWriter(Directory,
> IndexWriterConfiguration). What I was thinking of storing there are the
> following parameters:
> * All of ctors parameters, except for Directory.
> * The different setters where it makes sense. For example I still think
> infoStream should be set on IW directly.
> I'm thinking that IWC should expose everything in a setter/getter methods,
> and defaults to whatever IW defaults today. Except for Analyzer which will
> need to be defined in the ctor of IWC and won't have a setter.
> I am not sure why MaxFieldLength is required in all IW ctors, yet IW declares
> a DEFAULT (which is an int and not MaxFieldLength). Do we still think that
> 10000 should be the default? Why not default to UNLIMITED and otherwise let
> the application decide what LIMITED means for it? I would like to make MFL
> optional on IWC and default to something, and I hope that default will be
> UNLIMITED. We can document that on IWC, so that if anyone chooses to move to
> the new API, he should be aware of that ...
> I plan to deprecate all the ctors and getters/setters and replace them by:
> * One ctor as described above
> * getIndexWriterConfiguration, or simply getConfig, which can then be queried
> for the setting of interest.
> * About the setters, I think maybe we can just introduce a setConfig method
> which will override everything that is overridable today, except for
> Analyzer. So someone could do iw.getConfig().setSomething();
> iw.setConfig(newConfig);
> ** The setters on IWC can return an IWC to allow chaining set calls ... so
> the above will turn into
> iw.setConfig(iw.getConfig().setSomething1().setSomething2());
> BTW, this is needed for Parallel Indexing (see LUCENE-1879), but I think it
> will greatly simplify IW's API.
> I'll start to work on a patch.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
