Hello :) I think it has been the intention of the dev community for a long time to start using the flex parser framework, and in this regard this contribution is much welcome as a kickstarter for that. I have not looked much at the code, but I hope it could be a starting point for writing future parsers in a less "spaghetti" way.
One question. Say we want to add a new operator such as NEAR/N. Ideally this should be added in Lucene, then all the Solr QParsers extending the lucene flex parser would benefit from the same new operator. Would this be easily achieved with your code you think? We also have a ton of feature requests on the eDisMax parser for new kinds of query syntax support. Before we start implementing that on top of the already-hard-to-maintain eDismax code, we should think about re-implementing eDismax on top of flex, perhaps on top of Roman's contrib here? -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 14. mai 2013 kl. 17:07 skrev Roman Chyla <roman.ch...@gmail.com>: > Hello World! > > Following the recommended practice I'd like to let you know that I am about > to start porting our existing query parser into JIRA with the aim of making > it available to Lucene/SOLR community. > > The query parser is built on top of the flexible query parser, but it > separates the parsing (ANTLR) and the query building - it allows for a very > sophisticated custom logic and has self-retrospecting methods, so one can > actually 'see' what is going on - I have had lots of FUN working with it > (which I consider to be a feature, not a shameless plug ;)). > > Some write up is here: > http://29min.wordpress.com/category/antlrqueryparser/ > > You can see the source code at: > https://github.com/romanchyla/montysolr/tree/master/contrib/antlrqueryparser > > > If you think this project is duplicating something or even being useless (I > hope not!) please let me know, stop me, say something... > > Thank you! > > roman
