With the new QP we can build out a syntax that's compatible with GData and be able to embed location/spatial queries directly into the query string. (i.e. @+40.75-074.00 + 5mi)
SQL like range queries (i.e. [megapixel >= 3.0]) On Tue, Aug 11, 2009 at 10:44 PM, Jason Rutherglen<jason.rutherg...@gmail.com> wrote: > 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
