I think we shouldn't discuss too many different things here.
To begin I'd just like to introduce the IndexConfig class, that will
hold the parameters we currently pass to the different IndexWriter
constructors.
If we later need to create different IndexWriter impls we can introduce
a factory.
> I think AS is overkill for conveying configuration of IW/IR?
Agree.
> It's too cumbersome, I think, for something that ought to be simple.
> I'd prefer a dedicated config class with strongly typed setters
> exposed. Of all the "pure syntax" options so far I'd still prefer the
> traditional "con
Michael McCandless wrote:
> I think AS is overkill for conveying configuration of IW/IR?
>
> Suddenly, instead of:
>
> cfg.setRAMBufferSizeMB(128.0)
>
> I'd have to do something like this?
>
>
> cfg.addAttribute(IndexWriterRAMBufferSizeAttribute.class).setRAMBufferSize(128.0)
>
> It's too cumb
Hi Mike,
> I think AS is overkill for conveying configuration of IW/IR?
>
> Suddenly, instead of:
>
> cfg.setRAMBufferSizeMB(128.0)
>
> I'd have to do something like this?
>
>
> cfg.addAttribute(IndexWriterRAMBufferSizeAttribute.class).setRAMBufferSize
> (128.0)
>
> It's too cumbersome, I
I think AS is overkill for conveying configuration of IW/IR?
Suddenly, instead of:
cfg.setRAMBufferSizeMB(128.0)
I'd have to do something like this?
cfg.addAttribute(IndexWriterRAMBufferSizeAttribute.class).setRAMBufferSize(128.0)
It's too cumbersome, I think, for something that ought to
> > See my second mail. The recently introduced Attributes and
> AttributeSource
> > would solve this. Each component just defines its attribute interface
> and
> > impl class and you pass in an AttributeSource as configuration. Then you
> can
> > do:
> >
> > AttributeSource cfg = new AttributeSour
On Mon, Oct 5, 2009 at 12:01, Uwe Schindler wrote:
> Hi Marvin,
>
>> > Property names are always String, values any type (therefore
>> Map).
>> > With Java 5, integer props and so on are no "bad syntax" problem because
>> of
>> > autoboxing (no need to pass new Integer() or Integer.valueOf()).
>>
Hi Marvin,
> > Property names are always String, values any type (therefore
> Map).
> > With Java 5, integer props and so on are no "bad syntax" problem because
> of
> > autoboxing (no need to pass new Integer() or Integer.valueOf()).
>
> Argument validation gets to be a headache when you pass ar
On Mon, Oct 05, 2009 at 08:27:20AM +0200, Uwe Schindler wrote:
> Pass a Properties or Map to the ctor/open. The keys are predefined
> constants. Maybe our previous idea of an IndexConfiguration class is a
> subclass of HashMap with all the constants and some easy-to-use
> setter methods for very o
> > On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote:
> >
> > > 1 Do we prevent config settings from changing after creating an
> > > IW/IR?
> >
> > Any settings conveyed via a settings object ought to be final if you
> want
> > pluggable index components. Otherwise, you ne
> On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote:
>
> > 1 Do we prevent config settings from changing after creating an
> > IW/IR?
>
> Any settings conveyed via a settings object ought to be final if you want
> pluggable index components. Otherwise, you need some nightm
On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote:
> 1 Do we prevent config settings from changing after creating an
> IW/IR?
Any settings conveyed via a settings object ought to be final if you want
pluggable index components. Otherwise, you need some nightmarish notifica
On Sun, Oct 04, 2009 at 03:04:13PM -0400, Mark Miller wrote:
> Earwin Burrfoot wrote:
> > As I stated in my last email, there's zero difference between
> > settings+static factory and builder except for syntax. Cannot
> > understand what Mark, Mike are arguing about.
> >
> Sounds like we are arg
Earwin Burrfoot wrote:
> As I stated in my last email, there's zero difference between
> settings+static factory and builder except for syntax. Cannot
> understand what Mark, Mike are arguing about.
>
Sounds like we are arguing that we don't like the syntax then...
> kill setting methods that de
As I stated in my last email, there's zero difference between
settings+static factory and builder except for syntax. Cannot
understand what Mark, Mike are arguing about.
Right now I offer to do two things, in any possible way - eradicate as
much broken/spahetti-like runtime state change from IW and
On Sun, Oct 4, 2009 at 5:53 AM, Michael McCandless
wrote:
> 1 Do we prevent config settings from changing after creating an
> IW/IR?
>
> 2 Do we use factory or ctor to create IW/IR?
>
> On #1, we are technically taking something away. Are we sure no users
> find the freedom to change IW sett
I don't think we should do both. Suddenly, all code snippets (in
javadocs, tutorials, email we all send, etc.) can be one pattern or
the other, with each of us choosing based on our preference. Or,
mixed.
I think this just causes confusion. It'd suddenly become alot like
differences of opinion
> >> The builder pattern and the config argument to a factory both have the
> >> advantage that you can limit changes after creating an object. Some
> >> things are just bad to change in mid-stream. The config argument is
> >> nice in that you can pass it around to different stake holders, but
>
On 10/4/09 3:31 AM, Mark Miller wrote:
Ted Dunning wrote:
The builder pattern and the config argument to a factory both have the
advantage that you can limit changes after creating an object. Some
things are just bad to change in mid-stream. The config argument is
nice in that you can pass
Ted Dunning wrote:
>
> The builder pattern and the config argument to a factory both have the
> advantage that you can limit changes after creating an object. Some
> things are just bad to change in mid-stream. The config argument is
> nice in that you can pass it around to different stake holder
The builder pattern and the config argument to a factory both have the
advantage that you can limit changes after creating an object. Some things
are just bad to change in mid-stream. The config argument is nice in that
you can pass it around to different stake holders, but the builder can be
use
I think my preference is swayed by convention/simplicity. The way things
are done now are just very intuitive for me. When I sit down to write
some code with Lucene, I barley have to think or remember much. It all
sticks. Its mostly all basic Java with few patterns.
Now google has used some cool p
On 10/3/09 4:18 AM, Earwin Burrfoot wrote:
Builder pattern allows you to switch concrete implementations as you
please, taking parameters into account or not.
Besides that there's no real difference. I prefer builder, but that's just me :)
Why can't you do that with a factory that takes a
phi.de]
> Sent: Saturday, October 03, 2009 2:00 PM
> To: java-dev@lucene.apache.org
> Subject: RE: Lucene 2.9 and deprecated IR.open() methods
>
> This seems to work, I have created some scripts that do the compilations
> and
> create a deprecation report and I start to fix in B
28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> > -Original Message-
> > From: Uwe Schindler [mailto:u...@thetaphi.de]
> > Sent: Saturday, October 03, 2009 12:33 PM
> > To: java-dev@lucene.apache.org
> > Subject: RE: Lucene 2.9 and depr
On Oct 2, 2009, at 7:33 PM, Michael McCandless wrote:
Sigh. The introduction of new but deprecated methods is silly. Is
there some simple automated way to catch/prevent these?
The proliferation of ctors/factory methods is a nightmare.
Ah, so yet again, we are trying to work around a proble
[mailto:u...@thetaphi.de]
> Sent: Saturday, October 03, 2009 12:33 PM
> To: java-dev@lucene.apache.org
> Subject: RE: Lucene 2.9 and deprecated IR.open() methods
>
> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
> > Sent: Saturday, October 03, 2009 12:29 PM
&
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Saturday, October 03, 2009 12:29 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
>
> On Sat, Oct 3, 2009 at 6:25 AM, Uwe Schindler wrote:
> > Now it get
On Sat, Oct 3, 2009 at 6:25 AM, Uwe Schindler wrote:
> 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.
Sigh. Yes, going forward we should proba
nt: 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!)
ache.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 ;)
/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
>&g
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
>
> The
-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 wrote:
Call me old f
>> Builder pattern allows you to switch concrete implementations as you
>> please, taking parameters into account or not.
>
> We could also achieve this w/ static "factory" method. EG
> IndexReader.open(IndexReader.Config) could switch between concrete
> impls (it already does today).
Yes, the cho
>> 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 wrote:
>> >> Call me old fashioned, but I like how the non constructo
ss.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 wrote:
> >> Call me old fashioned, but I like how the non constructor params ar
On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot 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 w
On Fri, Oct 2, 2009 at 10:18 PM, Earwin Burrfoot wrote:
> Builder pattern allows you to switch concrete implementations as you
> please, taking parameters into account or not.
We could also achieve this w/ static "factory" method. EG
IndexReader.open(IndexReader.Config) could switch between con
Again - random opinion from left field - I've used guice and I like it
a lot. Really cool stuff and I actually prefer it to Spring for
injection. But still for some reason I'd hate to see Lucene start
resembling anything in Guice.
I'm not even taking the time to make arguments, so I don't e
On Oct 2, 2009, at 10:18 PM, Earwin Burrfoot 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
> 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,
> Though what about required settings? EG IW's builder must have
> Directory, Analyzer. Would we pass these as up-front args to the
> initial builder?
I'd try to keep required settings at minimum. The only one absolutely
required, imho, is a Directory, and it's best to specify it in
create() meth
Call me old fashioned, but I like how the non constructor params are set
now.
And for some reason I like a config object over a builder pattern for
the required constructor params.
Thats just me though.
Michael McCandless wrote:
> OK, I agree, using the builder approach looks compelling!
>
> Tho
OK, I agree, using the builder approach looks compelling!
Though what about required settings? EG IW's builder must have
Directory, Analyzer. Would we pass these as up-front args to the
initial builder?
And shouldn't we still specify the version up-front so we can improve
defaults over time wit
://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Saturday, October 03, 2009 1:33 AM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
>
> Sigh. The in
On Sat, Oct 3, 2009 at 03:29, Uwe Schindler wrote:
>> It is also probably a good idea to move various settings methods from
>> IW to that builder and have IW immutable in regards to configuration.
>> I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB,
>> setMergePolicy, setMergeS
n:
http://google-collections.googlecode.com/svn/trunk/javadoc/com/google/
common/collect/MapMaker.html
> > -Original Message-
> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
> > Sent: Saturday, October 03, 2009 1:37 AM
> > To: java-dev@lucene.apache.org
> >
il: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Saturday, October 03, 2009 1:37 AM
> To: java-dev@lucene.apache.org
> Subject: Re: Lucene 2.9 and deprecated IR.open() methods
>
> I think this would make sense.
I think this would make sense... though, it'd be a shame if the
"simple case" becomes overbearing. Maybe we can keep good defaults,
but use Version to allow us to change them. So eg:
new IndexWriter(new IndexWriter.Config(dir, analyzer, Version.LUCENE_29));
would be the "simple" case.
Mike
Sigh. The introduction of new but deprecated methods is silly. Is
there some simple automated way to catch/prevent these?
The proliferation of ctors/factory methods is a nightmare.
Part of the story with IndexReader.open is the switch to readOnly
IndexReaders. After the long back-compat discus
> It is also probably a good idea to move various settings methods from
> IW to that builder and have IW immutable in regards to configuration.
> I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB,
> setMergePolicy, setMergeScheduler, setSimilarity.
>
> IndexWriter.Builder iwb =
It is also probably a good idea to move various settings methods from
IW to that builder and have IW immutable in regards to configuration.
I'm speaking of the likes of setWriteLockTimeout, setRAMBufferSizeMB,
setMergePolicy, setMergeScheduler, setSimilarity.
IndexWriter.Builder iwb = IndexWriter.
I was thinking lately about the large quantity of IndexWriter
constructors and IndexReader open methods. I'm not sure if this has been
proposed before, but what if we introduced new objects, e.g.
IndexWriterConfig and IndexReaderConfig. They would contain
getter/setter methods for all the diffe
54 matches
Mail list logo
