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 I do that? I should
still copy the entire SyntaxParser logic, and modify these two places,
right?
By copying, I also copy existing bugs. If say someone fixes a bug which is
not related at all to the change above, how do I merge it? By default I
won't inherit it, and I'll need to manually apply the patch to my now
private version of SyntaxParser, even though 90% of it is still the original
Lucene parser.
And if someone augments the current syntax or parser w/ better parsing of
boolean queries. How do I take advantage of that?
W/ the opaque terms above, I should not have any problem w/ that. If I want
to have a Spatial syntax, I write a Spatial parser. If I want to have a
different range queries syntax, I write my own Range parser. If someone
fixes a bug in core parser, or improves how other sections of the syntax are
handled, I get those for free, because I never touch the parser's logic.
The new QP, AFAIU, does not help me in this case. All it gives me are some
helper classes (Builders, Processors maybe). But my core problem is the
syntax. 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.
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. Then, we can have a discussion about whether the new QP allows us to
support it more easily or not. If say we have an interface QueryParser w/ a
single parse(String) method which returns a Query object. Do we really care
how this QP was written? Whether it uses the new QP framework or something
else?
Shai
On Wed, Aug 12, 2009 at 10:43 AM, Shai Erera <ser...@gmail.com> wrote:
> 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? What are the benefits the new QP has
> when you come to deal w/ such terms? Unless you're talking about extending
> the Lucene syntax w/ spatial clauses. Just for my education, how do you
> extend the new QP w/ this information? Can you extend the Tokenizer, or do
> you need to write a new one?
>
> I'm trying to separate between the query syntax and a QP. The new QP is
> more of a framework for how to parse queries. It's well architected and
> designed. It allows to build different QPs for different syntaxes easily.
>
> As for the query syntax, what if we had augmented Lucene query syntax w/
> opaque clauses support. Something like @qpname::'query string'. Then, we can
> add to a QP a QP mapping from qpname to QP instance. That would allow anyone
> to use Lucene's QP and write new QPs (however they want) to match different
> opaque clauses.
>
> For the example above, I could write this query: "restaurants
> @spatial::'@+40.75-074.00
> + 5mi' " (quotes are not part of the query string) and instantiate the QP as
> follows:
> QueryParser qp = new QueryParser();
> qp.addQueryParser("spatial", new SpatialQueryParser());
> qp.parse(queryString);
>
> Upon parsing, the default QP would hit the opaque clause and defer parsing
> of the text in between ' to SpatialQueryParser. We'd need to come up w/ a
> simple QP interface, with a parse() method or something that it can call.
> Nothing too fancy.
>
> SpatialQueryParser could be implemented however we choose. Not necessarily
> using the new QP framework.
>
> Maybe we should add this to Lucene anyway, and the new QP would just make
> the implementations easier.
>
> BTW, in case I managed to make a wrong impression - I'm not against the new
> QP :).
>
> Shai
>
>
> On Wed, Aug 12, 2009 at 8:53 AM, Jason Rutherglen <
> jason.rutherg...@gmail.com> wrote:
>
>> 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<jason.rutherg...@gmail.com> wrote:
>> > 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 far).
>> >
>> > Thanks to the contrib query parser team!
>> >
>> > On Tue, Aug 11, 2009 at 10:54 AM, Mark Miller<markrmil...@gmail.com>
>> 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 at all yet. Its interfaces
>> (which
>> >> will need to abide by back compat in core) have not been vetted enough.
>> >>
>> >> The new parser appears to add complication to some of things that were
>> very
>> >> simple with the old parser.
>> >>
>> >> The main benefits of the new parser are claimed to be the ability to
>> plug
>> >> and play many syntaxes and QueryBuilders. This is not an end user
>> benefit
>> >> though and I'm not even sure how much of a benefit it is to us. There
>> is
>> >> currently only one impl. It seems to me, once you start another impl,
>> its a
>> >> long shot that the exact same query tree representation is going to
>> work
>> >> with a completely different syntax. Sure, if you are just doing postfix
>> >> rather than prefix, it will be fine – but the stuff that would likely
>> be
>> >> done – actual new syntaxes – are not likely to be very pluggable. If a
>> >> syntax can map to the same query tree, I think we would likely stick to
>> a
>> >> single syntax – else suffer the confusion and maintenance headaches for
>> >> syntactic sugar. More than a well factored QueryParser that can more
>> easily
>> >> allow different syntaxes to map to the same query tree representation,
>> I
>> >> think we just want a single solid syntax for core Lucene that supports
>> Spans
>> >> to some degree. We basically have that now, sans the spans support.
>> Other,
>> >> more exotic QueryParsers should live in contrib, as they do now.
>> >>
>> >> Which isn't to say this QueryParser should not one day rule the roost –
>> but
>> >> I don't think its earned the right yet. And I don't think there is a
>> hurry
>> >> to toss the old parser.
>> >>
>> >> Personally, I think that the old parser should not be deprecated. Lets
>> let
>> >> the new parser breath in contrib for a bit. Lets see if anyone actually
>> adds
>> >> any other syntaxes. Lets see if the pluggability results in any
>> >> improvements. Lets see if some of the harder things to do (overriding
>> query
>> >> build methods?) become easier or keep people from using the new parser.
>> >>
>> >> Lets just see if the new parser draws users without us forcing them to
>> it.
>> >> And lets also wait and see what other committers say – not many have
>> gotten
>> >> much time to deal with the new parser, or deal with user list questions
>> on
>> >> it.
>> >>
>> >> I just think its premature to start moving people to this new parser.
>> It
>> >> didn't even really get in until right before release – the paint on the
>> >> thing still reeks. There is no rush. I saw we undeprecate the current
>> >> QueryParser and remove the wording in the new QueryParser about it
>> replacing
>> >> the new in 3.0. Later, if we think it should replace it (after having
>> some
>> >> experience to judge from), we can reinstate the current plan. Anyone
>> agree?
>> >>
>> >> --
>> >> - Mark
>> >>
>> >> http://www.lucidimagination.com
>> >>
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> >>
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>>
>>
>
