lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Wed, 12 Aug 2009 08:51:25 GMT
>
> Is there any example when you cannot use the processing phase for that?
>

I actually meant that w/ the old QP I can also do it, by extending
QueryParser and overriding "newWildcardQuery(Term)". I'm sure this can be
done w/ the new QP as well. I just gave an example to something the new QP
does not allow me to do more easily.

About the opaque clauses and '@' - usually I'd think it's not the user who
writes such queries, but the application developer. Therefore the '@' does
not really matter.

Without opaque clauses, if I want to add some ability, like Spatial search
together w/ the other Lucene syntax, I will have a problem. I will need to
copy the SyntaxParser and add Spatial syntax to it. And with that I lose
whatever improvements that will be done on the default SyntaxParser.

We can not have the '@', but field::'some query', i.e., double colon (::)
and query string surrounded w/ '. Maybe that will look more native to the
user. We can perhaps have one colon (:) and ' to surround the query and
change the field handling to recognize this is an opaque field (because of
the '), but I don't know if this breaks the current syntax/parser.

Shai

On Wed, Aug 12, 2009 at 11:08 AM, Adriano Crestani <
adrianocrestani@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.
>
> 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