I like the idea of having syntax extensions,
and proposed something similar for ComplexPhraseQueryParser JIRA issue.
But we should create a new jira issue for this using the new queryparser,
this is a new feature an is not backward compatible with the current
lucene syntax.
For the syntax I
Thanks, Jason! Glad the new QP is useful for you.
I'd like to explain a bit the (IBM internal) history of this new QP: A
few years ago we wanted to change/extend Lucene's query syntax. We did
similar things as you mention, like no stemming for quoted terms,
additional syntax features, etc.
Michael, I wrote the above reply before I noticed you already replied.
Thanks for the explanation.
I guess that the way I see it, being able to extend a SyntaxParser is more
important than building my final Query object. If I want to enhance the
query syntax by replacing [] {} w/ = and =. How do
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
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
I don't think we should stick with the current path of replacing the
current QueryParser with the new contrib QueryParser in Lucene 3.0.
The new QueryParser has not been used much at all yet. Its interfaces
(which will need to abide by back compat in core) have not been vetted
enough.
The
+1, old QP should not be deprecated. Since the new one is in contrib,
it should just be stated that it doesn't necessarily have the same
back compat. issues as core, either that or it is marked as
experimental.
-Grant
On Aug 11, 2009, at 1:54 PM, Mark Miller wrote:
I don't think we
Yes, we should not deprecate the old one!
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Grant Ingersoll [mailto:gsing...@apache.org]
Sent: Tuesday, August 11, 2009 8:32 PM
To:
Agreed, don't deprecate our beloved QueryParser.
Erik
On Aug 11, 2009, at 1:54 PM, Mark Miller wrote:
I don't think we should stick with the current path of replacing the
current QueryParser with the new contrib QueryParser in Lucene 3.0.
The new QueryParser has not been used much
+1
Mike
On Tue, Aug 11, 2009 at 5:43 PM, Michael Buschbusch...@gmail.com wrote:
I agree we should not remove the old one in 3.0. That's way too early.
If we change the bw-policy we can replace it maybe in 3.1.
On 8/11/09 11:40 AM, Uwe Schindler wrote:
Yes, we should not deprecate the old
Mark,
I support not deprecating the current QP.
But I just wanted to comment on let's wait 'till people add more syntaxes.
I don't think that that's the issue here. The new QP is indeed useful for
plugging in different search syntaxes, but I personally don't believe that
in an application more
I'm starting to use the new parser to emulate Google's queries
(i.e. a phrase query with a single term means no-stemming,
something the current QP doesn't allow because it converts the
quoted query into a term query inside the JavaCC portion). It's
been very straightforward and logical to use (so
12 matches
Mail list logo
