The problems stems from a basic misunderstanding of how lucene queries work.
SQL queries imply a starting point of a full table of results, which are then filtered down. Lucene queries do not. You start with no results and find them through the provided query.
NOT FIELD2:STR
means: prohibit FIELD2:STR
. Nothing
prohibit Something
is still nothing. It does not mean get everything but FIELD2:STR
. That would be something like *:* -FIELD2:STR
, where *:*
is a MatchAllDocsQuery
(Note: The lucene query parser does not support *:*
. Solr does, Lucene doesn't). You can support this sort of query construction, but it's generally inadvisable, since it requires the entire set of documents in the index to be enumerated, which can result in very poor performance.
Lucene's +/- syntax is much more clear and flexible than it's confusing AND/OR/NOT syntax. +/- are how lucene queries are constructed (lucene terminology uses the labels SHOULD
, MUST
and MUST_NOT
). AND/OR/NOT get interpreted into those terms, and the interpretation is imperfect and leads to confusing issues like this.
For further reading on that topic: Why Not AND, OR, and NOT?