lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Morus Walter <>
Subject Re: Query Parser AND / OR
Date Tue, 30 Dec 2003 10:40:17 GMT
Dror Matalon writes:
> my $.02.
> Before having patches, I think it's a good idea to agree on what the
> "right" solution is. 
I tried to raise that question in the first place. But there wasn't much
So I decided to make a concrete suggestion, how to change things.

> Most of it is obvious using boolean logic, but we
> have some additional requirements like not having a query that only has
> a NOT clause. Is this the only exception?
To me the problem is, that there are two forms of queries
- boolean queries (a OR b AND c...)
- list of terms where some are flagged required and some are flagged forbidden
 (a +b -c ...) (in two forms: with default or and default and)

For each of these it seems pretty clear, what they mean, but if you start
to combine the two in one query, I don't know what that should mean.

What's the meaning of a OR b c +d ?
(Acutally there must be two meanings, one for default or, one for default and).
Maybe it's obvious, but I fail to see it.

> As far as the actual patch, I would suspect that a better approach than
> using java would be to use precedence operations in the actual parser.

Then you decide to do a complete rewrite of the query parser.
That's something I wanted to avoid.

I don't think that it matters how you implement a grammer though.
The problem here is, that you have to define the grammer first.

But I agree that doing it by JavaCC means is less error prone.

> Something like where
> different operators are grouped differently according to precedence
> would work better.
> As is often the case, trying to *correctly* parse a string is not
> trivial.
Right. Especially if there's no definition of correct...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message