Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of markrmiller@gmail.com
 designates 209.85.221.189 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=nJrpuLrWx/58yuKecDNoy7NktpXAxhh95XAx+fT5BZQQoNnsiph6LfqR++DS30Q81L
         J7OlXQoHFV2A8mbv6c15/Kr8FQiFPKhqmE3Ai967FgujHlEAqYQqJ4IMWE15ypmM3yPr
         z4tDKaVMy+fx9NAkx5DhOQiK5BEM7RRKsOTag=
Message-ID: <4AC9EBEA.5020407@gmail.com>
Date: Mon, 05 Oct 2009 08:51:54 -0400
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
References: <4AC698E4.1050606@gmail.com>
 <4AC865A3.9060003@gmail.com>	 <47ACC8E8A54B47DE8750162B0B501CE7@VEGA>
	 <9ac0c6aa0910040253l3d372857v63bc2c44e917c4e5@mail.gmail.com>
	 <20091004223723.GA2973@rectangular.com>
	 <848CB727CC3949F7AA1D72B0F96F1916@VEGA>
	 <20091005073541.GA7721@rectangular.com>
	 <DC0575DA815C4A359E06035F9003646D@VEGA>
	 <59b3eb370910050125u65feb8eak5c7b2955877c8790@mail.gmail.com>
	 <F2A66823C9C5418EAE2BF5803BD207E3@VEGA>
 <9ac0c6aa0910050511m1bd39a19na44f9ce4ce91c279@mail.gmail.com>
In-Reply-To: <9ac0c6aa0910050511m1bd39a19na44f9ce4ce91c279@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Michael McCandless wrote:
> I think AS is overkill for conveying configuration of IW/IR?
>
> Suddenly, instead of:
>
>   cfg.setRAMBufferSizeMB(128.0)
>
> I'd have to do something like this?
>
>   cfg.addAttribute(IndexWriterRAMBufferSizeAttribute.class).setRAMBufferSize(128.0)
>
> It's too cumbersome, I think, for something that ought to be simple.
> I'd prefer a dedicated config class with strongly typed setters
> exposed.  Of all the "pure syntax" options so far I'd still prefer the
> traditional "config object with setters".
>   
+1

> Also, I don't think we should roll this out for all Lucene classes.  I
> think most classes do just fine accepting args to their ctor.  EG
> TermQuery simply takes Term to its ctor.
>   
+1
> I do agree IW should not be in the business of brokering changes to
> the settings of its sub-components (eg mergeFactor, maxMergeDocs).
> You really should make such changes directly via your merge policy.
>   
Agreed we need to deal with - *but* I personally think it gets tricky.
Users should be able to flip compound on/off easily without dealing with
a mergepolicy IMO. And advanced users that set a mergepolicy shouldn't
have to deal with losing a compound setting they set with IW after
setting a new mergepolicy. Can't I have it both ways :)
> 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 <uwe@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-dev-help@lucene.apache.org
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-dev-help@lucene.apache.org
>
>   


-- 
- Mark

http://www.lucidimagination.com


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org