On Mon, Aug 3, 2009 at 3:59 PM, Adriano Crestani<adrianocrest...@gmail.com> wrote:
> Yes, it's the Lucene's "default" query parser implemented using the new QP > framework. OK. > Now, about moving it to oal.queryParser, I think it's a subjective decision. > I like it inside oal.queryParser.original, because > we can easily distinguish what is the "original" implementation. Well, naming is always the hardest part ;) And since we haven't released this yet, we're free to change it... I think it's more important, going forward, that Lucene presents a consumable API than that we preserve the history of what was new vs what was old from the past. EG fast forward 3 years and the line between "original" and "new" is not really important. I think it's more important that it's clear to users how you create Lucene's default QueryParser and get a Query from text. With the new query parser I now do this: import org.apache.lucene.queryParser.original.OriginalQueryParserHelper; OriginalQueryParserHelper parser = new OriginalQueryParserHelper(analyzer); The "original" and "helper" aren't that descriptive to users. In fact on seeing "original" I would sort of think maybe I should instead be looking for the "new" one to use. I'm hoping (by renaming to org.apache.lucene.queryParser.DefaultQueryParser) to be able to do this instead: import org.apache.lucene.queryParser.DefaultQueryParser DefaultQueryParser parser = new DefaultQueryParser(analyzer); >> Ie, is that (swapping in your own QueryBuilder) the right way to tweak >> how the DefaultQueryParser would create queries? > > If you want to be able to create NumericQuery objects based on the field > data type (float, int, date, etc), which the user specified in some kind of > configuration, changing the builders would not be enough, for these 2 > reasons: > > 1- Builders are meant to be used only to build the final objects from query > nodes, processing, like converting the range values to the correct data > format should be ideally be performed in a processor. > > 2- Builders have no access to configuration at build time, the only query > parser phase able to do that is the query processing phase. > > So, you will need to: > > - create an Attribute to hold the data type for each range field, so you can > set the data type on this attribute and add it to the QueryConfigHandler > (you may call originalQP.getQueryConfigHandler() to get it) > > - create a processor that reads this configuration from the > QueryConfigHandler and for each RangeQueryNode object and convert their > values to the correct format > > - add the processor to the current OriginalQueryParserPipeline (calling > defaultQP.getQueryNodeProcessor().addProcessor(new > MyNewRangeQueryNodeProcessor()) > > - create a builder that creates NumericQuery objects from RangeQueryNode and > add it to the builders' map: > defaultQP.getQueryBuilder().setBuilder(RangeQueryNode.class, new > MyRangeQueryNodeBuilder()) > > I think this is what should be done on LUCENE-1768. But, if you decide you > don't need to convert the range values based on the field data type > specified by the user and you want to hardcode that on the builder, you can > do the way you described. However, ideally, if you do any query processing, > like values conversion, you should create a processor for that, because they > were desinged for that. OK thanks for the clarification... that makes sense. So the builder should really be a "rote" translation of a query node into the corresponding Query. All "interesting" work should instead be done by the processors (or maybe the parser). Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
