Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of markrmiller@gmail.com
 designates 209.85.217.218 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
         :content-type:content-transfer-encoding;
        b=vvlBVpM7Fga1VuYu4oHlrWC4F/ILZAXJRgW4Ok4jA5hRsA8ebvlu55OQXMQLVy605G
         izbI80KHNVHaXNlOAWyc6SrKknrTB+ejJfnRvLOqAt9j5717bCZ1tWK+PriWijVnSLjG
         WszOVXxqjqNmnbmDrs7d0gkBQZBJOASbZplD4=
Message-ID: <4A81B04D.3010808@gmail.com>
Date: Tue, 11 Aug 2009 13:54:21 -0400
From: Mark Miller <markrmiller@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: The new Contrib QueryParser should not be slated to replace the old
 one yet
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

I don't think we should stick with the current path of replacing the 
current QueryParser with the new contrib QueryParser in Lucene 3.0.

The new QueryParser has not been used much at all yet. Its interfaces 
(which will need to abide by back compat in core) have not been vetted 
enough.

The new parser appears to add complication to some of things that were 
very simple with the old parser.

The main benefits of the new parser are claimed to be the ability to 
plug and play many syntaxes and QueryBuilders. This is not an end user 
benefit though and I'm not even sure how much of a benefit it is to us. 
There is currently only one impl. It seems to me, once you start another 
impl, its a long shot that the exact same query tree representation is 
going to work with a completely different syntax. Sure, if you are just 
doing postfix rather than prefix, it will be fine � but the stuff that 
would likely be done � actual new syntaxes � are not likely to be very 
pluggable. If a syntax can map to the same query tree, I think we would 
likely stick to a single syntax � else suffer the confusion and 
maintenance headaches for syntactic sugar. More than a well factored 
QueryParser that can more easily allow different syntaxes to map to the 
same query tree representation, I think we just want a single solid 
syntax for core Lucene that supports Spans to some degree. We basically 
have that now, sans the spans support. Other, more exotic QueryParsers 
should live in contrib, as they do now.

Which isn't to say this QueryParser should not one day rule the roost � 
but I don't think its earned the right yet. And I don't think there is a 
hurry to toss the old parser.

Personally, I think that the old parser should not be deprecated. Lets 
let the new parser breath in contrib for a bit. Lets see if anyone 
actually adds any other syntaxes. Lets see if the pluggability results 
in any improvements. Lets see if some of the harder things to do 
(overriding query build methods?) become easier or keep people from 
using the new parser.

Lets just see if the new parser draws users without us forcing them to 
it. And lets also wait and see what other committers say � not many have 
gotten much time to deal with the new parser, or deal with user list 
questions on it.

I just think its premature to start moving people to this new parser. It 
didn't even really get in until right before release � the paint on the 
thing still reeks. There is no rush. I saw we undeprecate the current 
QueryParser and remove the wording in the new QueryParser about it 
replacing the new in 3.0. Later, if we think it should replace it (after 
having some experience to judge from), we can reinstate the current 
plan. Anyone agree?

-- 
- Mark

http://www.lucidimagination.com


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