+1 Mike
On Tue, Aug 11, 2009 at 5:43 PM, Michael Busch<[email protected]> 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: [email protected] >> >> >>> >>> -----Original Message----- >>> From: Grant Ingersoll [mailto:[email protected]] >>> Sent: Tuesday, August 11, 2009 8:32 PM >>> To: [email protected] >>> 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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
