Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of earwin@gmail.com designates
 209.85.219.219 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=soMm/jHTwFBA4Uo6P7X6SyP6WnRBb5tlKnpo2ldNStG/FUtgcM/k1OenYlIt6gKzMO
         7GOjAcWzDDqWuDHKOibxtGC4M4pzaTVjecUkDOgHQUQR5zQFP3BFF7psEMHeVjr7YfGu
         apZajN4PwKuNKn0ZMWaX/cHMrQ/BjnUX5aumE=
MIME-Version: 1.0
In-Reply-To: <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com>
References: <C43B8A7D81E54A9E81AAD411C141E4DB@VEGA>
	 <4AC684B7.2040505@gmail.com>
	 <59b3eb370910021625r3854c09dw3c280143aed87b1a@mail.gmail.com>
	 <A25B297E93DD444EB37D8EAC118E6B48@VEGA>
	 <59b3eb370910021645l154f1ee9p14586927b93fbbef@mail.gmail.com>
	 <9ac0c6aa0910021715w6c67c26fwcd5b25d80d7b7217@mail.gmail.com>
Date: Sat, 3 Oct 2009 06:10:20 +0400
Message-ID: <59b3eb370910021910o27a74cf3ufde826a65f75053e@mail.gmail.com>
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
From: Earwin Burrfoot <earwin@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

> Though what about required settings? =C2=A0EG IW's builder must have
> Directory, Analyzer. =C2=A0Would 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() method, so you could set all your IW parameters and then
build several instances, for different Directories for example.

If you decide to add more required settings, we're back to square one
- after a couple of years we're looking at 14 builder() methods.
Okay, there is a way. Take a look at how Guice handles binding
declarations in Modules - different builder methods may return
different interfaces implemented by 'this'.

class IndexWriter {
  public static NoAnalyzerYetBuilder builder() { return new
HiddenTrueBuilder(); }

  interface NoAnalyzerYetBuilder {
     NoAnalyzerYetBuilder setRAMBuffer(...)
     NoAnalyzerYetBuilder setUseCompound(...)
     ....
     Builder setAnalyzer(Analyzer)
  }

  interface Builder extends NoAnalyzerYetBuilder {
     Builder setRAMBuffer(...)
     Builder setUseCompound (...)
     ....
     IndexWriter create(Directory)
  }

  private static class HiddenTrueBuilder implements Builder {
  }

  ....
}

This approach looks nice from client-side, but is a mess to implement.


> And shouldn't we still specify the version up-front so we can improve
> defaults over time without breaking back-compat? =C2=A0(Else, how can
> we change defaults?)
>
> EG:
>
> =C2=A0IndexWriter.builder(Version.29, dir, analyzer)
> =C2=A0 =C2=A0.setRAMBufferSizeMB(128)
> =C2=A0 =C2=A0.setUseCompoundFile(false)
> =C2=A0 =C2=A0...
> =C2=A0 =C2=A0.create()
>
> ?

It's probably okay to specify version upfront. But also, nothing bad
happens if we do it like:
IndexWriter.builder().
  defaultsFor(Version.29).
  setRam...........

> Mike
>
> On Fri, Oct 2, 2009 at 7:45 PM, Earwin Burrfoot <earwin@gmail.com> wrote:
>> On Sat, Oct 3, 2009 at 03:29, Uwe Schindler <uwe@thetaphi.de> 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, setMergeScheduler, setSimilarity.
>>>>
>>>> IndexWriter.Builder iwb =3D IndexWriter.builder().
>>>> =C2=A0 writeLockTimeout(0).
>>>> =C2=A0 RAMBufferSize(config.indexationBufferMB).
>>>> =C2=A0 maxBufferedDocs(...).
>>>> =C2=A0 similarity(...).
>>>> =C2=A0 analyzer(...);
>>>>
>>>> ... =3D iwb.build(dir1);
>>>> ... =3D iwb.build(dir2);
>>>
>>> A happy user of google-collections API :-) These builders are really co=
ol!
>>
>> I feel myself caught in the act.
>>
>> There is still a couple of things bothering me.
>> 1. Introducing a builder, we'll have a whole heap of deprecated
>> constructors that will hang there for eternity. And then users will
>> scream in frustration - This class has 14(!) constructors and all of
>> them are deprecated! How on earth am I supposed to create this thing?
>> 2. If someone creates IW with some reflectish javabeanish tools - he's
>> busted. Not that I'm feeling compassionate for such a person.
>>
>>> I like Earwin's version more. A builder is very flexible, because you c=
an
>>> concat all your properties (like StringBuilder works with its append me=
thod
>>> returning itself) and create the instance at the end.
>> Besides (arguably) cleaner syntax, the lack of which is (arguably) a
>> curse of many Java libraries,
>> it also allows us to return a different concrete implementation of IW
>> without breaking back-compat,
>> and also to choose this concrete implementation based on settings
>> provided. If we feel like doing it at some point.
>>
>> --
>> Kirill Zakharenko/=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =D0=97=D0=B0=D1=
=85=D0=B0=D1=80=D0=B5=D0=BD=D0=BA=D0=BE (earwin@gmail.com)
>> Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
>> ICQ: 104465785
>>
>> ---------------------------------------------------------------------
>> 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
>
>


--=20
Kirill Zakharenko/=D0=9A=D0=B8=D1=80=D0=B8=D0=BB=D0=BB =D0=97=D0=B0=D1=85=
=D0=B0=D1=80=D0=B5=D0=BD=D0=BA=D0=BE (earwin@gmail.com)
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org