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
<adrianocrest...@gmail.com <mailto: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
<mailto: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.
