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
n
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>
>>
>>>
>>> -Original Message-
>>> From: Grant Ingersoll [mailto:gsing...@apache.org
<mailto:gsing...@apache.o
Michael Busch wrote:
We should also realize that - thanks to Luis and Adriano - we now have
actual code that can be the basis of discussions and that we can take
and improve. No matter if this new QP is going to replace the old one
or not, I'm very thankful that the two went through the effor
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 th
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.
I think this way is cleaner :)
On Wed, Aug 12, 2009 at 1:51 AM, Shai Erera wrote:
> We
>
> 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
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 us
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
Some comments in line:
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.
Agreed, I still think some points must still be discussed about the API, and
to start discussing about it, the contributors m
>
> With the new QP we can build out a syntax that's compatible with
> GData and be able to embed location/spatial queries directly
> into the query string. (i.e. @+40.75-074.00 + 5mi)
>
What do you mean "with the new QP"? What prevents you from doing that w/o
the new QP, as in writing your own QP
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. Ver
With the new QP we can build out a syntax that's compatible with
GData and be able to embed location/spatial queries directly
into the query string. (i.e. @+40.75-074.00 + 5mi)
SQL like range queries (i.e. [megapixel >= 3.0])
On Tue, Aug 11, 2009 at 10:44 PM, Jason
Rutherglen wrote:
> I'm startin
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 f
; 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:
ailto:gsing...@apache.org]
>>> Sent: Tuesday, August 11, 2009 8:32 PM
>>> To: java-dev@lucene.apache.org
>>> Subject: Re: The new Contrib QueryParser should not be slated to replace
>>> the old one yet
>>>
>>> +1, old QP should not be deprecated. Since the
hi.de
eMail: u...@thetaphi.de
-Original Message-
From: Grant Ingersoll [mailto:gsing...@apache.org]
Sent: Tuesday, August 11, 2009 8:32 PM
To: java-dev@lucene.apache.org
Subject: Re: The new Contrib QueryParser should not be slated to replace
the old one yet
+1, old QP should n
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 a
+1
In other words: undeprecate our good friend 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
To: java-dev@lucene.apache.org
> Subject: Re: The new Contrib QueryParser should not be slated to replace
> the old one yet
>
> +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. i
+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 shoul
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 ne
21 matches
Mail list logo