lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adriano Crestani <adrianocrest...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Wed, 12 Aug 2009 08:08:08 GMT
If I want to control how Wildcard clauses are handled, I can do it w/
today's QP as well, just extend it and override the appropriate getter
method.

The SyntaxParser can produce WildcardQueryNode object which can further be
processed on the processing phase. Is there any example when you cannot use
the processing phase for that?

In conclusion, I think that if we want to have a truly extensible QP, we
should start w/ the query syntax first, and my proposal are those opaque
terms.

Agree, I also think we need to improve a lot the syntax parsing phase. It's
really simple and not extensible yet. Opaque terms are interesting, I just
don't think users will like to type '@' before the field names, actually the
user has no idea why he's typing that @, so there is no need for that. I
think we could do a mapping from field name to parser directly. Anyway, this
approach would only work for field:term syntaxes, any other different
syntax, like xml syntax, will need a different approach. I cannot think
about a generic API yet for this approach, any suggestions?

On Wed, Aug 12, 2009 at 12:54 AM, Shai Erera <serera@gmail.com> wrote:

> If I want to control how Wildcard clauses are handled, I can do it w/
> today's QP as well, just extend it and override the appropriate getter
> method.
>

Mime
View raw message