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
