Finally, I'm not convinced we should lock down all settings after
classes are created. (I'm not convinced we shouldn't, either).
A merge policy has no trouble changing its mergeFactor,
maxMergeDocs/Size. IW has no trouble changing the its RAM buffer
size, maxFieldLength, or useCompoundFile. Sure there are some things
that cannot (or would be very tricky to) change, eg deletion policy.
But then analyzer isn't changeable today, but could be.
But, then, I can also see it'd simplify our code to not have to deal
w/ such changes, reduce chance of subtle bugs, and it seems minor to
go and re-open your IndexWriter if you need to make a settings change?
(Hmm except in an NRT setting, because the reader pool would be reset;
really we need to get the reader pool separated from the IW instance).
Mike
On Mon, Oct 5, 2009 at 4:38 AM, Uwe Schindler<u...@thetaphi.de> wrote:
See my second mail. The recently introduced Attributes and
AttributeSource
would solve this. Each component just defines its attribute interface
and
impl class and you pass in an AttributeSource as configuration. Then
you
can
do:
AttributeSource cfg = new AttributeSource();
ComponentAttribute compCfg =
cfg.addAttribute(ComponentAttribute.class);
compCfg.setMergeScheduler(FooScheduler.class);
MergeBarAttribute mergeCfg =
cfg.addAttribute(MergeBarAttribute.class);
mergeCfg.setWhateverProp(1234);
...
IndexWriter iw = new IndexWriter(dir, cfg);
(this is just brainstorming not yet thoroughly thought about).
This approach suggests IW creates its components, and while doing so
provides them your AS instance.
I personally prefer creating all these components myself, configuring
them (at the moment of creation) and passing them to IW in one way or
another.
This requires way less code, you don't have to invent elaborate
schemes of passing through your custom per-component settings and
selecting which exact component types IW should use, you don't risk
construct/postConstruct/postpostConstruct-style things.
Not really. That was just brainstorming. But you can pass also instances
instead of class names through attributesource. AttributeSurce only
provides
type safety for the various configuration settings (which are
interfaces).
But you could also create an attribute that gets the pointer to the
component. So "compCfg.setMergeScheduler(FooScheduler.class);" could
also be
compConfig.addComponent(new FooScheduler(...));
The AttributeSource approach has one other good thing:
If you want to use the default settings for one attribute, you do not
have
to add it to the AS (or you can forget it). With the properties
approach,
you have to hardcode the parameter defaults and validation everywhere.
As
the consumer of an AttributeSource gets the attribute also by an
addAttribute-call (see current indexing code consuming TokenStreams),
this
call would add the missing attribute with its default settings defined
by
the implementation class. So in the above example, if you do not want to
provide the "whateverProp", leave the whole MergeBarAttribute out. The
consumer (IW) would just call addAttribute(MergeBarAttribute.class),
because
it needs the attribute to configure itself. AS would add this attribute
with
default settings.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
