lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <...@thetaphi.de>
Subject RE: The new Contrib QueryParser should not be slated to replace the old one yet
Date Tue, 11 Aug 2009 18:40:11 GMT
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


Mime
View raw message