lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: basic questions on the new QueryParser
Date Tue, 04 Aug 2009 03:18:10 GMT
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