lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 10:14:43 GMT
There's also LUCENE-1698! Maybe we can change the policy. Now that 2.9 
is out we should try to get to a conclusion.

  Michael

On 10/3/09 11:54 AM, Michael McCandless wrote:
> Well, let's first get 3.0 out the door ;)  Then we can salivate over
> all sorts of juicy changes for 3.1...
>
> These particular changes (switching syntax from multi-ctors to config
> or to builder, disallowing config changes after creation, switching to
> "concrete impl is hidden") may merit an exception to our back-compat
> policy.  Obviously users are bothered by the horror of how many ctors
> you are confronted with for IW and IR.
>
> Mike
>
> On Sat, Oct 3, 2009 at 5:46 AM, Uwe Schindler<uwe@thetaphi.de>  wrote:
>    
>> Hi,
>>
>> The problem is, we have to leave some of the not-yet-deprecated ctors/opens
>> available for a while (not until 4.0 with our ne policy), but a user
>> removing all deprecated stuff from his 2.9 release should be able to switch
>> to 3.0 without changing any code (can even plug the jars in). We also have
>> to keep the getters/setter avail. If we wanted to change this, 2.9 was the
>> best option :-(
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>>      
>>> -----Original Message-----
>>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>> Sent: Saturday, October 03, 2009 11:35 AM
>>> To: java-dev@lucene.apache.org
>>> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
>>>
>>> On Fri, 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.
>>>>          
>>> This is a good point: are you allowed to change config settings after
>>> creating your IndexWriter/Reader?
>>>
>>> Today it's ad hoc.
>>>
>>> EG IW does not allow you to swap out your deletion policy, because
>>> it'd be a nightmare to implement.  You also can't swap the analyzer.
>>> But it does let you change your RAM buffer size, CFS or not, merge
>>> factor, etc.  We can remove that flexibility (I'm not sure it's
>>> compelling), so we can make things final.  You can't change read-only
>>> after opening your IndexReader.  I think it'd make sense to move away
>>> from changing settings after construction...
>>>
>>> But: the "do we disallow changing config settings after construction?"
>>> question is really orthogonal to the "what syntax do we use for
>>> construction?" (builder vs config vs zillions-of-ctors).
>>>
>>> Mike
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>      
> ---------------------------------------------------------------------
> 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