lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Tue, 11 Aug 2009 22:03:04 GMT
+1

Mike

On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<buschmic@gmail.com> wrote:
> 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
>
>

---------------------------------------------------------------------
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