Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-13 Thread Luis Alves
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Mark Miller
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Mark Miller
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Michael Busch
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Adriano Crestani
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Shai Erera
> > 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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Adriano Crestani
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Shai Erera
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Adriano Crestani
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-12 Thread Shai Erera
> > 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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Michael Busch
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Jason Rutherglen
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Jason Rutherglen
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Shai Erera
; 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:

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Michael McCandless
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Michael Busch
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Erik Hatcher
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Erik Hatcher
+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

RE: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Uwe Schindler
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

Re: The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Grant Ingersoll
+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

The new Contrib QueryParser should not be slated to replace the old one yet

2009-08-11 Thread Mark Miller
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