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:25:05 GMT
Now it gets slower. After applying LUCENE-1944, you get >600 errors when
compiling tests :(

We should have checked our tests in 2.9 that they only call deprecated
methods for BW compatibility. No I have to change tons of IR.open(), IW()
calls in backwards branch and also in trunk tests. But the patch is
currently the same for both branches - puh.

Completely unhappy :-(

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 12:21 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
> 
> Right: 3.0 should be a fast turnaround w/ no further deprecations.
> (And at your rate of progress Uwe it looks like it really *will* be
> fast!).
> 
> For 3.1 we can salivate...
> 
> Mike
> 
> On Sat, Oct 3, 2009 at 6:18 AM, Uwe Schindler <uwe@thetaphi.de> wrote:
> > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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