lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25820] - [PATCH] QueryParser not handling queries containing AND and OR correctly
Date Thu, 12 Feb 2004 18:13:40 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25820>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25820

[PATCH] QueryParser not handling queries containing AND and OR correctly





------- Additional Comments From morus.walter@gmx.de  2004-02-12 18:13 -------
Thanks for you effort Otis.

I wasn't aware of the test cases and used only my own ones.

When I run the tests now, I do get these errors.
I had a closer look and find that these errors are due to intentional changes.

First I changed the test cases to deal with null queries returned from the query
parser, that is I changed the function assertQueryEquals to
  public void assertQueryEquals(String query, Analyzer a, String result)
    throws Exception {
    Query q = getQuery(query, a);
    String s = q != null ? q.toString("field") : "null";
    if (!s.equals(result)) {
      fail("Query /" + query + "/ yielded /" + s
           + "/, expecting /" + result + "/");
    }
  }

(the change is the construction of the result string 'String s = ...').

Then I get the following errors:

    [junit] Testcase:
testSimple(org.apache.lucene.queryParser.TestQueryParser):	FAILED
    [junit] Query /a OR !b/ yielded /a/, expecting /a -b/

intentional:
a OR !b means all documents that contain a or that don't contain b.
So this cannot be expressed by a single boolean query since it would implement a
AND !b. So a OR !b gets a OR (!b) and !b is a boolean query containing only
prohibited terms, which cannot be searched.
Therefor it's dropped.
I asked how to deal with that on the mailing list
(http://issues.apache.org/eyebrowse/ReadMsg?listName=lucene-user@jakarta.apache.org&msgNo=6497)
and Otis suggested to return null for such queries,
which means that it will get dropped.

    [junit] Testcase:
testNumber(org.apache.lucene.queryParser.TestQueryParser):	FAILED
    [junit] Query /3/ yielded /null/, expecting //
...
    [junit] Testcase: testQPA(org.apache.lucene.queryParser.TestQueryParser):	FAILED
    [junit] Query /stop/ yielded /null/, expecting //

Also intentional. Empty queries return null now, instead of a boolean
query containing no query.
Same question on the mailing list.

    [junit] Testcase: testBoost(org.apache.lucene.queryParser.TestQueryParser):
FAILED
    [junit] null
This is from 
   StandardAnalyzer oneStopAnalyzer = new StandardAnalyzer(new String[]{"on"});
    QueryParser qp = new QueryParser("field", oneStopAnalyzer);
    Query q = qp.parse("on^1.0");
    assertNotNull(q);
which is also a query containing only stopwords, that returns null now.


So I think this raises the question again, what should be the result of an empty
query?
A boolean query containing no clauses doesn't make much sense to me (the only
reason to use this would be compatiblity, since this is the old behavior).
For queries (and subqueries) containing only stopwords, an alternative would be
to raise an exception.

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


Mime
View raw message