Hi, I agree that people can register arbitrary qparsers, however the question might have been understoo differently - about the ANLR parser that can handle what solr qparser does (and that one is looking at _query_: and similar stuff -- or at local params, which is what can be copy&pasted into the business logic of the new parser; ie. the solution might be similar to what is already done in solr qparser)
I think I'm going to try just that :) So here is my working ANTLR grammar for Lucene in case anybody is interested: https://github.com/romanchyla/montysolr/tree/master/src/java/org/apache/lucene/queryParser/iqp/antlr And I plan to build now a wrapper that calls this parser to parse the query, get the tree, then translate the tree into lucene query object. The local stuff {} may not even be part of the grammar -- some unclear ideas in here, but they will be sorted out... roman On Wed, Aug 17, 2011 at 9:26 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : I'm looking for an ANTLR parser that consumes solr queries and filters. > : Before I write my own, thought I'd ask if anyone has one they are > : willing to share or can point me to one? > > I'm pretty sure that this will be imposisble to do in the general case -- > arbitrary QParser instances (that support arbitrary syntax) can be > registered in the solrconfig.xml and specified using either localparams or > defType. so even if you did write a parser that understood all of the > rules of all of hte default QParsers, and even if you made your parser > smart enough to know how to look at other params (ie: defType, or > variable substitution of "type") to understand which subset of parse rules > to use, that still might give false positives or false failures if hte > user registered their own QParser using a new name (or changed the > names used in registrating existing parsers) > > The main question i have is: why are you looking for an ANTLR paser to do > this? what is your goal? > > https://people.apache.org/~hossman/#xyproblem > Your question appears to be an "XY Problem" ... that is: you are dealing > with "X", you are assuming "Y" will help you, and you are asking about "Y" > without giving more details about the "X" so that we can understand the > full issue. Perhaps the best solution doesn't involve "Y" at all? > See Also: http://www.perlmonks.org/index.pl?node_id=542341 > > > > > -Hoss >