The query language is NOT pure boolean. Hoss wrote this up:
http://searchhub.org/2011/12/28/why-not-and-or-and-not/
Best
Erick
On Mon, Apr 15, 2013 at 12:54 PM, Roman Chyla wrote:
> Oh, sorry, I have assumed lucene query parser. I think SOLR qp must be
> different then, because for me it works a
Oh, sorry, I have assumed lucene query parser. I think SOLR qp must be
different then, because for me it works as expected (our qp parser is
identical with lucene in the way it treats modifiers +/- and operators
AND/OR/NOT -- NOT must be joining two clauses: a NOT b, the first cannot be
negative, a
What if you try
city:(*:* -H*) OR zip:30*
Sometimes Solr requires a list of documents to subtract from (think of "*:*
-someQuery" converts to "all documents without someQuery").
You can also try looking at your query with debugQuery = true.
-Luis
On Mon, Apr 15, 2013 at 12:25 PM, Peter Schüt
: Hallo,
: I do not really understand the query language of the SOLR-Queryparser.
http://www.lucidimagination.com/blog/2011/12/28/why-not-and-or-and-not/
The one comment i would add regarding your specific examples...
: (!city:H*) OR zip:30*numFound: 2896
...you can't have a boolean query
Hallo,
Roman Chyla wrote in
news:caen8dywjrl+e3b0hpc9ntlmjtrkasrqlvkzhkqxopmlhhfn...@mail.gmail.com:
> should be: -city:H* OR zip:30*
>
-city:H* OR zip:30* numFound:2520
gives the same wrong result.
Another Idea?
Ciao
Peter Schütt
should be: -city:H* OR zip:30*
On Mon, Apr 15, 2013 at 12:03 PM, Peter Schütt wrote:
> Hallo,
> I do not really understand the query language of the SOLR-Queryparser.
>
> I use SOLR 4.2 und I have nearly 20 sample address records in the
> SOLR-Database.
>
> I only use the "q" field in th
