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 buschmic@gmail.com designates
 72.14.220.153 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=DrxRh0L+guZUHELlEeV/g1xtgdJtUVcK4xR4Z3SMvb2B4zBZJtOixlEolTMwWtcT8N
         vFd/kqvLaAfpowELiACHU+OtsUn4ABtnDh6Y0YlyS8gmN/0aq7BgYgN+MQYfoIYjXS00
         B8OZsFedbLB9nbpPsOEH2zya6cx941JK4lM5g=
Message-ID: <4AC684B7.2040505@gmail.com>
Date: Sat, 03 Oct 2009 00:54:47 +0200
From: Michael Busch <buschmic@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.9 and deprecated IR.open() methods
References: <C43B8A7D81E54A9E81AAD411C141E4DB@VEGA>
In-Reply-To: <C43B8A7D81E54A9E81AAD411C141E4DB@VEGA>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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 different parameters the various 
constructors and open methods currently have. Then there would only be 
one IW constructor taking an IndexWriterConfig object as parameter and 
one open method in IR likewise. Then going forward we won't have to 
add/deprecate more ctors or open methods, we can then easily extend or 
deprecate getters/setters in the *Config classes.

  Michael

On 10/3/09 12:41 AM, Uwe Schindler wrote:
> When looking for press articles about the release of Lucene 2.9, I found the
> following one from Bernd Fondermann
> @ http://it-republik.de/jaxenter/artikel/Apache-Lucene-2.9-2594.html
>
> Translation with Google Translate:
> ----------------------------------------------------------------------------
> Deprecated
>
> An index reader is created via the static open () factory method, of which
> there were 2.4 in all nine. Five of them are now deprecated. In 2.9 there
> are now a total of 14 open-overloaded variants, with eight of them but they
> are deprecated. This means that there are even some additions that have been
> directly identified with introduction as deprecated - confusing.
>
> The constructor-Deprecation orgy goes for the standard Analyzer, one of the
> key classes during indexing and querying further. This class has now no-less
> constructor arguments over what might, perhaps, some downstream libraries
> bring to stumble to instantiate their analyzer on a property, which contains
> the class name dynamically. Instead, an object version must be given to set
> for compatibility with 2.4 or 2.9. Both the VERSION_24 as well as the
> VERSION_29 parameters are deprecated but themselves - very confusing!
> VERSION_CURRENT is the only safe investment in the future, a value which we
> certainly also as assignment in a zero-argument constructor would have
> trusted.
>
> To write an index we need an index writer instance. Again, the majority of
> the 19 possible constructors are about to be put to retire to.
> ----------------------------------------------------------------------------
>
> What was going wrong with the open() hell in IR? Very strange, I should have
> looked better.
>
> By the way: How to proceed with deprecation removal? Case-by-case (e.g.
> start with TS API, then these open() calls, then FSDirectory - to list the
> ones I was involved) or some hyper-patch?
>
> By the way, here is my talk @ Hadoop GetTogether in Berlin:
>
> http://blog.isabel-drost.de/index.php/archives/category/events/apache-hadoop
> -get-together-berlin
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>
>
> ---------------------------------------------------------------------
> 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