lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luis Alves (JIRA)" <>
Subject [jira] Commented: (LUCENE-167) [PATCH] QueryParser not handling queries containing AND and OR
Date Tue, 25 Aug 2009 08:29:59 GMT


Luis Alves commented on LUCENE-167:

This feature is part of the new queryparser implementation
It is disabled by the by default, to implement the lucene 2.4 behaviour.
It can be enabled by removing the GroupQueryNodeProcessor from the StandardQueryNodeProcessorPipeline.

In LUCENE-1823 we plan to expose it in a new syntax parser and also handle OR, AND, NOT as
logical operators with precedence.

Would be this enough to address this issue?

> [PATCH] QueryParser not handling queries containing AND and OR
> --------------------------------------------------------------
>                 Key: LUCENE-167
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: QueryParser
>    Affects Versions: unspecified
>         Environment: Operating System: Linux
> Platform: PC
>            Reporter: Morus Walter
>            Assignee: Erik Hatcher
>         Attachments:, QueryParser.jj.patch, QueryParser.patch
> The QueryParser does not seem to handle boolean queries containing AND and OR
> operators correctly:
> e.g.
> a AND b OR c AND d gets parsed as +a +b +c +d.
> The attached patch fixes this by changing the vector of boolean clauses into a
> vector of vectors of boolean clauses in the addClause method of the query
> parser. A new sub-vector is created whenever an explicit OR operator is used.
> Queries using explicit AND/OR are grouped by precedence of AND over OR. That is
> a OR b AND c gets a OR (b AND c).
> Queries using implicit AND/OR (depending on the default operator) are handled as
> before (so one can still use a +b -c to create one boolean query, where b is
> required, c forbidden and a optional).
> It's less clear how a query using both explizit AND/OR and implicit operators
> should be handled.
> Since the patch groups on explicit OR operators a query 
> a OR b c is read as a (b c)
> whereas
> a AND b c as +a +b c
> (given that default operator or is used).
> There's one issue left:
> The old query parser reads  a query 
> `a OR NOT b' as `a -b' which is the same as `a AND NOT b'.
> The modified query parser reads this as `a (-b)'.
> While this looks better (at least to me), it does not produce the result of a OR
> NOT b. Instead the (-b) part seems to be silently dropped.
> While I understand that this query is illegal (just searching for one negative
> term) I don't think that silently dropping this part is an appropriate way to
> deal with that. But I don't think that's a query parser issue.
> The only question is, if the query parser should take care of that. 
> I attached the patch (made against 1.3rc3 but working for 1.3final as well) and
> a test program.
> The test program parses a number of queries with default-or and default-and
> operator and reparses the result of the toString method of the created query.
> It outputs the initial query, the parsed query with default or, the reparesed
> query, the parsed query with the default and it's reparsed query.
> If called with a -q option, it also run's the queries against an index
> consisting of all documentes containing one or none a b c or d.
> Using an unpatched and a patched version of lucene in the classpath one can look
> at the effect of the patch in detail.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

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

View raw message