lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luis Alves <lafa...@gmail.com>
Subject Re: basic questions on the new QueryParser
Date Tue, 04 Aug 2009 20:11:33 GMT
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: uwe@thetaphi.de
>
> ------------------------------------------------------------------------
>
> *From:* Adriano Crestani [mailto:adrianocrestani@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 
> <lucene@mikemccandless.com <mailto:lucene@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message