No, that's what Solr would do if the bug were fixed. Matching all documents
(*:*) is a "constant score query", so it takes no significant amount of
resources. Personally, I consider this a bug in Lucene, but try convincing
them of that!
The issue was filed as:
SOLR-3744 - "Solr LuceneQParser only handles pure negative queries at the
top-level query, but not within parenthesized sub-queries"
https://issues.apache.org/jira/browse/SOLR-3744
And:
SOLR-3729 - "ExtendedDismaxQParser (edismax) doesn't parse (*:*) properly"
https://issues.apache.org/jira/browse/SOLR-3729
-- Jack Krupansky
-----Original Message-----
From: Brett Hoerner
Sent: Tuesday, July 1, 2014 4:06 PM
To: solr-user@lucene.apache.org
Subject: Re: Confusion about location of + and - ?
Interesting, is there a performance impact to sending the *:*?
On Tue, Jul 1, 2014 at 2:53 PM, Jack Krupansky <j...@basetechnology.com>
wrote:
Yeah, there's a known bug that a negative-only query within parentheses
doesn't match properly - you need to add a non-negative term, such as
"*:*". For example:
text:(+"happy") AND user:(*:* -"123456789")
-- Jack Krupansky
-----Original Message----- From: Brett Hoerner
Sent: Tuesday, July 1, 2014 2:51 PM
To: solr-user@lucene.apache.org
Subject: Confusion about location of + and - ?
Can anyone explain the difference between these two queries?
text:(+"happy") AND -user:("123456789") = numFound 2912224
But
text:(+"happy") AND user:(-"123456789") = numFound 0
Now, you may just say "then just put - infront of your field, duh!" Well,
text:(+"happy") = numFound 2912224
user:(-"123456789") = numFound 465998192
(FWIW there is no user named 123456789 in my index)
As you can see, the queries work alone, but when combined with an AND I
always get 0 results. If I move the - before the field in my query, it
works. What am I missing here?
Thanks.
