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
is:
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!
L
On 11/16/06, Chris Hostetter <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
