Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <4A81E615.60209@gmail.com>
References: <4A81B04D.3010808@gmail.com>
	 <6A9EE10F-47F0-41A3-9F46-BDD98F1135A5@apache.org>
	 <D3AD8D418A2B499290E5D82B98CAA7EE@VEGA> <4A81E615.60209@gmail.com>
Date: Tue, 11 Aug 2009 18:03:04 -0400
Message-ID: <9ac0c6aa0908111503j348b0b9bi840cb58ffb2d1b8b@mail.gmail.com>
Subject: Re: The new Contrib QueryParser should not be slated to replace the
	old one yet
From: Michael McCandless <lucene@mikemccandless.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+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 replac=
e
>>> the old one yet
>>>
>>> +1, old QP should not be deprecated. =A0Since 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