I'm trying to get started with the new (flexible) QueryParser, in
contrib.

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?

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?

Mike

---------------------------------------------------------------------

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 <
[EMAIL PROTECTED]> 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

Thanks for this howto; maybe I can try to do this for LUCENE-1768 as some
exercise at the end of the week :-) - 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: [EMAIL PROTECTED]

  _____  

From: Adriano Crestani [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 03, 2009 10:00 PM
To: [EMAIL PROTECTED]
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
<[EMAIL PROTECTED]> 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?

 

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?

Yes, as far as the processors know how to process the node your text parser
creates. The QP framework was really designed to have processing decoupled
from the syntax.

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.

I plan to do it, I just need to find some free time :)

On Mon, Aug 3, 2009 at 1:11 PM, Uwe Schindler <[EMAIL PROTECTED]> wrote:

> 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?

On Mon, Aug 3, 2009 at 3:59 PM, Adriano
Crestani<[EMAIL PROTECTED]> 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

---------------------------------------------------------------------

Michael McCandless wrote:
>
>
> 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).
>  
Hi Mike,

Only the Processors should do "interesting" work, it is the only API
that has access
to the QueryConfigHandler by design.

QueryConfigHandler - should hold all the information necessary to
generate queries for the
specified index or system where it is being used. Example: field
configuration, index configuration,
any other configuration that is useful to generate the queries.

SyntaxParser implementation should avoid doing "interesting" work, it
should do the minimum
to create a syntax a tree that represents the user query and pass it to
a QueryNodeProcessor
pipeline for the "interesting" work.

--
-Lafa

Mike - isn't "fast forwarding 3 years" means that the current QP will be
removed, together w/ the OriginalQPHelper and we'll have just one QP? And
I'd think we'll want to call it Default or something, so users can
distinguish between it (which parses the Lucene query syntax) and another
custom parser they wrote for their own syntax.

I agree that the current name is not too descriptive, but perhaps since it's
just temporary it's not that bad? Add to that that 'Default' might be used
after 3.0 to refer to the new QP which parses the Lucene syntax, and users
will be confused w/ the 'Default' in 2.9 vs. the new one.

Maybe we can call it OldQPHelper, to encourage people to move faster to the
new one?

Shai

On Tue, Aug 4, 2009 at 2:47 AM, Luis Alves <[EMAIL PROTECTED]> wrote:

>  Michael McCandless wrote:
>
>
> 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).
>
>
>  Hi Mike,
>
> Only the Processors should do "interesting" work, it is the only API that
> has access
> to the QueryConfigHandler by design.
>
> QueryConfigHandler - should hold all the information necessary to generate
> queries for the
> specified index or system where it is being used. Example: field
> configuration, index configuration,
> any other configuration that is useful to generate the queries.
>
> SyntaxParser implementation should avoid doing "interesting" work, it
> should do the minimum
> to create a syntax a tree that represents the user query and pass it to a
> QueryNodeProcessor
> pipeline for the "interesting" work.
>
> --
> -Lafa
>
>
>

The "original" and "helper" aren't that descriptive to users.

It's named "helper" because it extends QueryParserHelper, that's the only
reason. I think it's ok to rename "original" to something else. . I also
share Mike's opinion, I prefer "default" over "original".

Mike - isn't "fast forwarding 3 years" means that the current QP will be
removed, together w/ the OriginalQPHelper and we'll have just one QP?

OriginalQPHelper is not intended to be removed, it should be the new simple
way to use the query parser. So, I agree with Mike, now is the best time to
name it, while it's not released yet.

On Mon, Aug 3, 2009 at 8:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:

> Mike - isn't "fast forwarding 3 years" means that the current QP will be
> removed, together w/ the OriginalQPHelper and we'll have just one QP? And
> I'd think we'll want to call it Default or something, so users can
> distinguish between it (which parses the Lucene query syntax) and another
> custom parser they wrote for their own syntax.
>
> I agree that the current name is not too descriptive, but perhaps since
> it's just temporary it's not that bad? Add to that that 'Default' might be
> used after 3.0 to refer to the new QP which parses the Lucene syntax, and
> users will be confused w/ the 'Default' in 2.9 vs. the new one.
>
> Maybe we can call it OldQPHelper, to encourage people to move faster to the
> new one?
>
> Shai
>
>
> On Tue, Aug 4, 2009 at 2:47 AM, Luis Alves <[EMAIL PROTECTED]> wrote:
>
>>  Michael McCandless wrote:
>>
>>
>> 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).
>>
>>
>>  Hi Mike,
>>
>> Only the Processors should do "interesting" work, it is the only API that
>> has access
>> to the QueryConfigHandler by design.
>>
>> QueryConfigHandler - should hold all the information necessary to generate
>> queries for the
>> specified index or system where it is being used. Example: field
>> configuration, index configuration,
>> any other configuration that is useful to generate the queries.
>>
>> SyntaxParser implementation should avoid doing "interesting" work, it
>> should do the minimum
>> to create a syntax a tree that represents the user query and pass it to a
>> QueryNodeProcessor
>> pipeline for the "interesting" work.
>>
>> --
>> -Lafa
>>
>>
>>
>

OK I will open an issue to further iterate on this...

Mike

On Tue, Aug 4, 2009 at 1:34 AM, Adriano
Crestani<[EMAIL PROTECTED]> wrote:
> The "original" and "helper" aren't that descriptive to users.
>
> It's named "helper" because it extends QueryParserHelper, that's the only
> reason. I think it's ok to rename "original" to something else. . I also
> share Mike's opinion, I prefer "default" over "original".
>
> Mike - isn't "fast forwarding 3 years" means that the current QP will be
> removed, together w/ the OriginalQPHelper and we'll have just one QP?
>
> OriginalQPHelper is not intended to be removed, it should be the new simple
> way to use the query parser. So, I agree with Mike, now is the best time to
> name it, while it's not released yet.
>
> On Mon, Aug 3, 2009 at 8:18 PM, Shai Erera <[EMAIL PROTECTED]> wrote:
>>
>> Mike - isn't "fast forwarding 3 years" means that the current QP will be
>> removed, together w/ the OriginalQPHelper and we'll have just one QP? And
>> I'd think we'll want to call it Default or something, so users can
>> distinguish between it (which parses the Lucene query syntax) and another
>> custom parser they wrote for their own syntax.
>>
>> I agree that the current name is not too descriptive, but perhaps since
>> it's just temporary it's not that bad? Add to that that 'Default' might be
>> used after 3.0 to refer to the new QP which parses the Lucene syntax, and
>> users will be confused w/ the 'Default' in 2.9 vs. the new one.
>>
>> Maybe we can call it OldQPHelper, to encourage people to move faster to
>> the new one?
>>
>> Shai
>>
>> On Tue, Aug 4, 2009 at 2:47 AM, Luis Alves <[EMAIL PROTECTED]> wrote:
>>>
>>> Michael McCandless wrote:
>>>
>>> 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).
>>>
>>>
>>> Hi Mike,
>>>
>>> Only the Processors should do "interesting" work, it is the only API that
>>> has access
>>> to the QueryConfigHandler by design.
>>>
>>> QueryConfigHandler - should hold all the information necessary to
>>> generate queries for the
>>> specified index or system where it is being used. Example: field
>>> configuration, index configuration,
>>> any other configuration that is useful to generate the queries.
>>>
>>> SyntaxParser implementation should avoid doing "interesting" work, it
>>> should do the minimum
>>> to create a syntax a tree that represents the user query and pass it to a
>>> QueryNodeProcessor
>>> pipeline for the "interesting" work.
>>>
>>> --
>>> -Lafa
>>>
>>
>
>

---------------------------------------------------------------------

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: [EMAIL PROTECTED]
>
> ------------------------------------------------------------------------
>
> *From:* Adriano Crestani [mailto:[EMAIL PROTECTED]]
> *Sent:* Monday, August 03, 2009 10:00 PM
> *To:* [EMAIL PROTECTED]
> *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
-Lafa

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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
>>
>> ------------------------------------------------------------------------
>>
>> *From:* Adriano Crestani [mailto:[EMAIL PROTECTED]]
>> *Sent:* Monday, August 03, 2009 10:00 PM
>> *To:* [EMAIL PROTECTED]
>> *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