[
https://issues.apache.org/jira/browse/LUCENE-2294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841535#action_12841535
]
Shai Erera commented on LUCENE-2294:
------------------------------------
There are some settings on IW that go directly to the MergePolicy used (well
... only if it's LogMergePolicy). At first I wanted to move them, together w/
MP, to IWC, but this isn't possible, because MP requires IW to be passed to its
ctor, and when IWC is created, there is no IW ... So there are couple of
options I can think of:
* Add all to IWC, and expose on MP a final setIndexWriter, package-private, as
well as an empty ctor. IW will later set MP's IW. It will also allow
applications to pass their own MP after IW has been created (like they can do
today). IWC will delegate all set/get to MP, like IW does today. The only
downside is that the IW member of MP won't be final anymore ...
* Keep the get/set on IW, like it is today. It will split the configuration of
IW to two places ... I prefer to keep it all in one place.
* Remove all the set/get from IW and let applications interface directly with
MP. It will remove the bizarre situation where someone could pass a non
LogMergePolicy to IW, however when he'll try to set anything on it from IW, it
will fail ... If we remove the get/set from IW and let folks interface w/ their
MP directly, we won't have this problem:
** They'll need to declare the MP of type LogMP, or otherwise the API won't be
there.
** if they use their own MP, with special API, they'll interface w/ MP's
configuration from one place ...
Between the three, I like (3) the best as it will get rid of the inconsistency
in IW today (expecting only LogMP, but requiring MP). But if those set/get are
important to keep together with the other configuration, I prefer (1). What do
you think?
> 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
>
>
> 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
