lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adriano Crestani <adrianocrest...@gmail.com>
Subject Re: basic questions on the new QueryParser
Date Tue, 04 Aug 2009 20:25:18 GMT
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 <lafadev@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: 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