lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grant Ingersoll <>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Tue, 11 Aug 2009 18:31:30 GMT
+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  


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