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 05:34:47 GMT
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 <serera@gmail.com> 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 <lafadev@gmail.com> 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
>>
>>
>>
>

Mime
View raw message