lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Tue, 11 Aug 2009 21:43:49 GMT
I agree we should not remove the old one in 3.0. That's way too early.
If we change the bw-policy we can replace it maybe in 3.1.

On 8/11/09 11:40 AM, Uwe Schindler wrote:
> Yes, we should not deprecate the old one!
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
>    
>> -----Original Message-----
>> From: Grant Ingersoll [mailto:gsingers@apache.org]
>> Sent: Tuesday, August 11, 2009 8:32 PM
>> To: java-dev@lucene.apache.org
>> Subject: Re: The new Contrib QueryParser should not be slated to replace
>> the old one yet
>>
>> +1, old QP should not be deprecated.  Since the new one is in contrib,
>> it should just be stated that it doesn't necessarily have the same
>> back compat. issues as core, either that or it is marked as
>> experimental.
>>
>> -Grant
>>
>> On Aug 11, 2009, at 1:54 PM, Mark Miller wrote:
>>
>>      
>>> 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
>>>
>>>        
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>    


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


Mime
View raw message