I'm starting to use the new parser to emulate Google's queries (i.e. a phrase query with a single term means no-stemming, something the current QP doesn't allow because it converts the quoted query into a term query inside the JavaCC portion). It's been very straightforward and logical to use (so far).
Thanks to the contrib query parser team! On Tue, Aug 11, 2009 at 10:54 AM, Mark Miller<markrmil...@gmail.com> 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
