lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 09:54:01 GMT
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


Mime
View raw message