Hi Mike, If so, maybe we should rename "OriginalQueryParserHelper" to "DefaultQueryParser" and perhaps move it up into oal.queryParser?
I rather not have any specific implementation code to be placed outside its package. In future we will probably have a ComplexPhraseQueryParserHelper when the new complex phrase QP impl is finished, I would rather it inside oal.queryParser.complexPhrase than in oal.queryParser. So I would want the same for the default|original QP impl. On Tue, Aug 4, 2009 at 1:11 PM, Luis Alves <lafa...@gmail.com> wrote: > Hi Uwe, > > The junit TestSpanQueryParserSimpleSample is a testcase that uses the > OriginalSyntaxParser to parse > the text, and it uses a SpansValidatorQueryNodeProcessor, > UniqueFieldQueryNodeProcessor and a > SpanOrQueryNodeBuilder to create a lucene SpanTermQuery. > > I think is a good initial example how to extend and use the framework, for > other scenarios. > > Another interesting feature of the "new Flexible Query Parser" "original" > implementation > is that most QueryNodeTree's can be convert back to lucene text queries and > vice-versa, > even if the QueryNodeTree is created in programmatic way. > > Uwe Schindler wrote: > >> >> Thanks for this howto; maybe I can try to do this for LUCENE-1768 as some >> exercise at the end of the week J - I was not able to look into the new >> framework in detail (I only looked into the Powerpoints on Michael B’s >> Linkedin profile page), but it would be good to have a howto like this mail >> somewhere in the wiki or docs. >> >> If I read it correctly, the parsing of the query string is decoupled from >> this. So somebody could also create another query syntax and reuse all >> processors and builders? >> >> In my opinion, Solr could also use this query parser framework and >> implement all these special field-specific things like that. >> >> ----- >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> ------------------------------------------------------------------------ >> >> *From:* Adriano Crestani [mailto:adrianocrest...@gmail.com] >> *Sent:* Monday, August 03, 2009 10:00 PM >> *To:* java-dev@lucene.apache.org >> *Subject:* Re: basic questions on the new QueryParser >> >> I see the "original" package, and the useful OriginalQueryParserHelper >> within there, that are meant to ease the transition off of the old >> QueryParser to the new one. >> >> First question: is the original package also intended to be Lucene's >> "default" QueryParser, going forward? Ie, most users will simply want >> to get Lucene's default QueryParser and parse text into Query objs, >> and then expert users will directly use core.* to make their own query >> parsers. >> >> If so, maybe we should rename "OriginalQueryParserHelper" to >> "DefaultQueryParser" and perhaps move it up into oal.queryParser? >> >> Yes, it's the Lucene's "default" query parser implemented using the new QP >> framework. >> We already discussed what name should be given to it (original, standard, >> default, main, etc) on LUCENE-1567, that >> is why we picked the name "original", but there is no specific reason why >> we picked it over the others. >> >> 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. But like >> I said, it's really subjective. >> >> Second question: say I wanted to start with the DefaultQueryParser, >> but tweak how it produces range queries. EG the old QueryParser >> attempted to parse the lower/upper bounds as Date, and then re-encodes >> them using DateTools (LUCENE-1768 is already open to do this plus >> NumericQuery "for real"... I'm just using it as a use case of how an >> outside consumer of this API could tweak the default QueryParser). >> >> If I want to do this using the new QueryParser, could I: >> >> * First get the DefaultQueryParser >> >> * Call getQueryBuilder to get its QueryBuilder >> >> * Call QueryBuilder.setBuilder( >> >> RangeQueryNode.class, new >> MyRangeQueryNodeBuilder()), where MyRangeQueryNodeBuilder is my >> new class that handles the dates. >> >> ? >> >> 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. >> >> Best Regards, >> Adriano Crestani Campos >> >> On Mon, Aug 3, 2009 at 11:12 AM, Michael McCandless < >> luc...@mikemccandless.com <mailto:luc...@mikemccandless.com>> wrote: >> >> Second question: say I wanted to start with the DefaultQueryParser, >> but tweak how it produces range queries. EG the old QueryParser >> attempted to parse the lower/upper bounds as Date, and then re-encodes >> them using DateTools (LUCENE-1768 is already open to do this plus >> NumericQuery "for real"... I'm just using it as a use case of how an >> outside consumer of this API could tweak the default QueryParser). >> >> If I want to do this using the new QueryParser, could I: >> >> * First get the DefaultQueryParser >> >> * Call getQueryBuilder to get its QueryBuilder >> >> * Call QueryBuilder.setBuilder(RangeQueryNode.class, new >> MyRangeQueryNodeBuilder()), where MyRangeQueryNodeBuilder is my >> new class that handles the dates. >> >> ? >> >> Ie, is that (swapping in your own QueryBuilder) the right way to tweak >> how the DefaultQueryParser would create queries? >> >> > > -- > -Lafa > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
