[
https://issues.apache.org/jira/browse/LUCENE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12842241#action_12842241
]
Michael McCandless commented on LUCENE-2294:
--------------------------------------------
OK let's keep the semantics of "if you pass null that means restore to default".
Should we rename UNLIMITED_FIELD_LENGTH -> DEFAULT_MAX_FIELD_LENGTH? (Though
w/ the new issue this should be going away from IWC anyway).
bq. IWC.toString() includes '\n' between settings
Ahh, I misread it (I thought IW was doing \n followed by single space). I
agree multiple lines is much better. How about making IW also do multiple
lines for its non-IWC settings that are messaged? And then removing the
config= from the output? Ie all I see is a bunch of settings. I don't think
[in this debug printout] that we need to message which setting was on IW and
which was from the IWC.
bq. 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).
Ahh, sorry, right. Annoying we moved IW as required into MP :( Hrmph.
bq. I think I'll just clone the incoming IWC on IW and leave the rest as-is?
OK, I think this is fine, for starters. The API semantics are clearly defined,
so, if at a later date we harden the enforcement (say throw IllegalStateEx if
you try to change anything after IWC has been consumed by IW, that's fair game).
Maybe clearly state in the jdocs that presently no settings are version
dependent, so it's just a placeholder? (Basically, elevate the code comment
that already says this, into the jdocs). Whenever a class in Lucene takes a
Version, we should strongly document how Version alters settings, even if it's
a no-op placeholder. (And I agree we should have it here as placeholder).
Patch looks good Shai, thanks!
> 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
> Assignee: Michael McCandless
> Fix For: 3.1
>
> Attachments: LUCENE-2294.patch, 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
