lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Busch <busch...@gmail.com>
Subject Re: The new Contrib QueryParser should not be slated to replace the old one yet
Date Wed, 12 Aug 2009 09:34:26 GMT
I think opaque terms is a good and useful feature and we have discussed 
that several times and experimentally implemented in the past.

However I think that should be separate discussion/feature request. It 
solves a different problem.

  Michael

On 8/12/09 1:51 AM, Shai Erera wrote:
>
>     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 <mailto: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
>     <mailto: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