Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43FB9300.2080005@net-frame.com>
Date: Tue, 21 Feb 2006 17:24:00 -0500
From: Terry Steichen <terry@net-frame.com>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: Lucene 1.9 RC1 release available
References: <43FB4438.8070409@apache.org>
In-Reply-To: <43FB4438.8070409@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

In reviewing the latest changes incorporated into release 1.9 RC1, I 
noticed a change responding to JIRA item LUCENE-306.  According to the 
writeup, the new change forces the wildcard pattern 'cat??' to exactly 
match the length of the term (in this case, a five-letter term starting 
with 'cat'). 

If my understanding of this change is correct, I'm concerned that this 
will actually make some fairly common query expressions more difficult 
to construct. 

For example, let's say that I'm interested in docs with terms 'riot', 
'riots', 'rioting' and 'rioters' (which, I think, is a reasonable kind 
of query).  Under the previous versions of QueryParser, I could simply 
specify 'riot???' and capture all of those variants. 

With the new change (if I understand it correctly), I would have to 
either spell out all the individual terms, or specify something like 
'(riot riot? riot???)'.  I can see that there might be some cases where 
you might want to get only term matches of a specific length; however, 
IMHO, those needs would be far less common than the kind of needs I've 
tried to illustrate with 'riot???'.

I have a personal interest in that this new change will force me to 
change and retest a large number of pre-defined, fairly complex 
queries.  If it is deemed important to have the new capability, could we 
perhaps incorporate a flag that could be set to override the change and 
QueryParser using the previous logic on this?


Doug Cutting wrote:

> Release 1.9 RC1 of Lucene is now available from:
>
> http://www.apache.org/dyn/closer.cgi/lucene/java/
>
> This release candidate has many improvements since release 1.4.3, 
> including new features, performance improvements, bug fixes, etc.  For 
> details, see:
>
> http://svn.apache.org/viewcvs.cgi/*checkout*/lucene/java/branches/lucene_1_9/CHANGES.txt?rev=379190 
>
>
> 1.9 will be the last 1.x release. It is both back-compatible with 
> 1.4.3 and forward-compatible with the upcoming 2.0 release. Many 
> methods and classes in 1.4.3 have been deprecated in 1.9 and will be 
> removed in 2.0.  Applications must compile against 1.9 without 
> deprecation warnings before they are compatible with 2.0.
>
> Doug
>
> ---------------------------------------------------------------------
> 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