lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <j...@apache.org>
Subject [jira] Commented: (LUCENE-2294) Create IndexWriterConfiguration and store all of IW configuration there
Date Thu, 04 Mar 2010 21:29:30 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message