lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 03:25:14 GMT




On Oct 2, 2009, at 10:18 PM, Earwin Burrfoot <earwin@gmail.com> wrote:

>> Call me old fashioned, but I like how the non constructor params  
>> are set
>> now.
> And what happens when you index some docs, change these params, index
> more docs, change params, commit? Let's throw in some threads?
> You either end up writing really hairy state control code, or just
> leave it broken, with "Don't change parameters after you start pumping
> docs through it!" plea covering your back somewhere in JavaDocs.
> If nothing else, having stuff 'final' keeps JIT really happy.
>
>> And for some reason I like a config object over a builder pattern for
>> the required constructor params.
> Builder pattern allows you to switch concrete implementations as you
> please, taking parameters into account or not.
> Besides that there's no real difference. I prefer builder, but  
> that's just me :)

Nope. So far it's you and a couple others ;)

>
>> Thats just me though.
>>
>> Michael McCandless wrote:
>>> OK, I agree, using the builder approach looks compelling!
>>>
>>> Though what about required settings?  EG IW's builder must have
>>> Directory, Analyzer.  Would we pass these as up-front args to the
>>> initial builder?
>>>
>>> And shouldn't we still specify the version up-front so we can  
>>> improve
>>> defaults over time without breaking back-compat?  (Else, how can
>>> we change defaults?)
>>>
>>> EG:
>>>
>>>   IndexWriter.builder(Version.29, dir, analyzer)
>>>     .setRAMBufferSizeMB(128)
>>>     .setUseCompoundFile(false)
>>>     ...
>>>     .create()
>>>
>>> ?
>>>
>>> Mike
>>>
>>> On Fri, Oct 2, 2009 at 7:45 PM, Earwin Burrfoot <earwin@gmail.com>  
>>> wrote:
>>>
>>>> On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <uwe@thetaphi.de>  
>>>> wrote:
>>>>
>>>>>> It is also probably a good idea to move various settings  
>>>>>> methods from
>>>>>> IW to that builder and have IW immutable in regards to  
>>>>>> configuration.
>>>>>> I'm speaking of the likes of setWriteLockTimeout,  
>>>>>> setRAMBufferSizeMB,
>>>>>> setMergePolicy, setMergeScheduler, setSimilarity.
>>>>>>
>>>>>> IndexWriter.Builder iwb = IndexWriter.builder().
>>>>>>   writeLockTimeout(0).
>>>>>>   RAMBufferSize(config.indexationBufferMB).
>>>>>>   maxBufferedDocs(...).
>>>>>>   similarity(...).
>>>>>>   analyzer(...);
>>>>>>
>>>>>> ... = iwb.build(dir1);
>>>>>> ... = iwb.build(dir2);
>>>>>>
>>>>> A happy user of google-collections API :-) These builders are  
>>>>> really cool!
>>>>>
>>>> I feel myself caught in the act.
>>>>
>>>> There is still a couple of things bothering me.
>>>> 1. Introducing a builder, we'll have a whole heap of deprecated
>>>> constructors that will hang there for eternity. And then users will
>>>> scream in frustration - This class has 14(!) constructors and all  
>>>> of
>>>> them are deprecated! How on earth am I supposed to create this  
>>>> thing?
>>>> 2. If someone creates IW with some reflectish javabeanish tools -  
>>>> he's
>>>> busted. Not that I'm feeling compassionate for such a person.
>>>>
>>>>
>>>>> I like Earwin's version more. A builder is very flexible,  
>>>>> because you can
>>>>> concat all your properties (like StringBuilder works with its  
>>>>> append method
>>>>> returning itself) and create the instance at the end.
>>>>>
>>>> Besides (arguably) cleaner syntax, the lack of which is  
>>>> (arguably) a
>>>> curse of many Java libraries,
>>>> it also allows us to return a different concrete implementation  
>>>> of IW
>>>> without breaking back-compat,
>>>> and also to choose this concrete implementation based on settings
>>>> provided. If we feel like doing it at some point.
>>>>
>>>> --
>>>> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail 
>>>> .com)
>>>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>>>> ICQ: 104465785
>>>>
>>>> --- 
>>>> ------------------------------------------------------------------
>>>> 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
>>
>>
>
>
>
> -- 
> Kirill Zakharenko/Кирилл Захаренко (earwin@gmail.com)
> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
> ICQ: 104465785
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message