lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Tue, 11 Aug 2009 20:42:54 GMT
Agreed, don't deprecate our beloved QueryParser.


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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message