> > 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 < adrianocrest...@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 <ser...@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. >> > >
