lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: basic questions on the new QueryParser
Date Mon, 03 Aug 2009 21:22:47 GMT
On Mon, Aug 3, 2009 at 3:59 PM, Adriano
Crestani<> wrote:

> Yes, it's the Lucene's "default" query parser implemented using the new QP
> framework.


> 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

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).


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message