lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucifer Hammer" <>
Subject Re: Another problem with the QueryParser
Date Thu, 16 Nov 2006 20:41:14 GMT
 Hi Chris,

Thanks for your response.  If it's alright with you,  I'd like to spell it
out, just so you can confirm that I'm understanding what you're saying:

Here's the Query: "Table OR NOT Chair"

I thought the results I should expect are:
    All documents in the index that have the word "Table" and all documents
in the index that don't have the word "Chair"

However, if I understand what you're saying, then what's really happening
   Find all documents in the index with the word "Table", and then from that
list, remove any  docs that don't have "Chair"?

If the latter is true, then how are these two queries different:
     "Table OR NOT Chair"
     "Table AND NOT Chair"

Along these same lines, I would've expected a query of "NOT Table" to return
all the docs in the index that don't contain "Table",  kinda like "* NOT
Table" (where * represents all the docs in the index). However, if I
understood what you said, this will return no results, cause there isn't any
portion of query that adds docs to the result set.

Thanks again for all your help!


On 11/16/06, Chris Hostetter <> wrote:
> your first query only returns one document because there is only one
> clause selecting results -- it doesn't matter whether you write "Table AND
> NOT Chair" or "Table OR NOT Chair" -- the only clause building up a list
> of documents is "Table" ... the "NOT Chair" part of the query can only
> take away documents.
> As i mentioned in response to your last question about QueryParser....
> >       ...i strongly encourage you to train yourself to think in
> > terms of MUST, MUST_NOT and SHOULD (which are represented in the query
> > parser as the prefixes "+", "-" and the default) instead of in terms of
> > AND, OR, and NOT ... Lucene's BooleanQuery (and thus Lucene's
> QueryParser)
> > is not a strict Boolean Logic system, so it's best not to try and think
> > of it like one.
> If it were up to me, QueryParser wouldn't recognize AND OR and NOT as
> keywords, in my experience they cause nothing but confusion...
> : since NOT is a unary operator, I'm not sure I understand.
> the key is that NOT isn't the only unary operator -- AND and OR are also
> unary, they just map to the clauses on both sides unless the clause on one
> side alreayd has another op ... they are also badly named, their real
> names are MUST and SHOULD.  the way ot think about your query is ...
>        Table OR NOT Chair =>    SHOULD(Table) NOT(Chair)
> ...that may not make any more sense then it did before, but hopefully thta
> just further illustrates my point that using AND OR and NOT is an evil
> thing to do ... avoid them like the plauge and use "+" and "-" instead.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message