lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: Lucene 2.9 and deprecated IR.open() methods
Date Sat, 03 Oct 2009 10:18:41 GMT
But we should not change for 3.0, because people have already much to do to
get their 2.9 compile without deprec. If the work is then obsolete, because
we change this fundamental, we will make a lot of people angry. So I would
do this for 3.1.

-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de


> -----Original Message-----
> From: Michael Busch [mailto:buschmic@gmail.com]
> Sent: Saturday, October 03, 2009 12:15 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
> 
> 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



---------------------------------------------------------------------
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