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: u...@thetaphi.de > -----Original Message----- > From: Michael McCandless [mailto:luc...@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 <u...@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: u...@thetaphi.de > > > > > >> -----Original Message----- > >> From: Michael Busch [mailto:busch...@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<u...@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: u...@thetaphi.de > >> >> > >> >> > >> >>> -----Original Message----- > >> >>> From: Michael McCandless [mailto:luc...@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<ear...@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-unsubscr...@lucene.apache.org > >> >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> >>> > >> >> > >> >> > >> >> -------------------------------------------------------------------- > - > >> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> >> > >> >> > >> >> > >> > --------------------------------------------------------------------- > >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >> > > >> > > >> > > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
