On 5/14/2013 1:44 PM, Lee, Peter wrote: > The cause: > We had an unintentional case that occurred through one request handler such > that after the query was processed through the RH and the parameters were > set, there were fq variables set but no actual "q" (query) param. > - Under solr 3.5, solr seems to assume you MEANT to specify q=*:* > - Under solr 4.2.1, solr makes no such assumption (or so it seems). It > appears as if solr has decided that since we didn't bother to include a 'q' > parameter, it isn't going to bother to search for anything (yes, I'm > anthropomorphizing...it was a late night). I tried the same query with the > same request handler back and forth between the two versions of solr server > and one returned my data set and the other gave me zero hits.
I can't seem to duplicate this behavior. If I send a request to 3.5.0 with no q parameter and an fq parameter, I get an exception: http://server35:port/solr/ncmain/select?rows=0&fq=field:value -- HTTP ERROR 500 Problem accessing /solr/ncmain/select. Reason: null java.lang.NullPointerException -- If I send the same request to a 4.2.1 server, I get a response, but numFound is zero: http://server421:port/solr/ncmain/select?rows=0&fq=field:value I *had* thought that if you include q.alt=*:* in your request handler definition it would fall back to that, but that appears to only be the case if you are using the dismax/edismax query parser, not the standard parser. I have a different request handler for edismax which includes q.alt in the definition, and the queries above work fine when using that handler instead of /select. One thing that would most likely work is to include the q parameter in the defaults section of your request handler. If you don't include it in your query, it would pick up the default, but if you did include it, the default would be ignored. Thanks, Shawn
