lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dror Matalon <d...@zapatec.com>
Subject Re: Query Parser AND / OR
Date Tue, 30 Dec 2003 18:35:59 GMT
Hi,

First, let me say something that wasn't obvious from my first mail.
While I had opinions about the implementation, I have a lot of respect
for your finding a problem, and going ahead and coding a solution.

On Tue, Dec 30, 2003 at 11:40:17AM +0100, Morus Walter wrote:
> 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
> responce.

Might be the time of the year when many people are busy with other
stuff.

> 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.

You're right, it is confusing. Assuming default OR I would gess that the
above means 
b c +d 
and assuming default AND it would mean
+b +c +d 
Is there another interpretation?

> 
> > 
> > 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.

Ouch. I think you might be right. It might be a good idea to move this
discussion to lucene-dev where we'd get more attention from the
developers. This seems more like a developer issue than a user issue.

> 
> 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 http://www.lysator.liu.se/c/ANSI-C-grammar-y.html 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...
> 


> Morus
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
> 

-- 
Dror Matalon
Zapatec Inc 
1700 MLK Way
Berkeley, CA 94709
http://www.fastbuzz.com
http://www.zapatec.com

---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message