Yes, we should not deprecate the old one! ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de
> -----Original Message----- > From: Grant Ingersoll [mailto:gsing...@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-unsubscr...@lucene.apache.org > > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org