Sounds like I may not have all of the conditions correctly identified. Or rather, things in our environment that I did not think were a factor may very well be. For one thing, I see I neglected to mention that this was a grouping (field collapsing) query. Let me give you more complete information about the query...it will probably help.
I can tell you that after the request handler processing was complete, these were the only parameters that were set in the query: q - was not set defType = edismax df = <was set> echoParams = explicit rows = 100 start = 0 fq = <was set> group = true group.field = <was set> group.limit = 1 group.offset = 0 group.cache.percent = 100 fl = <set to various fields> shards = <set to the list of shards> All of the above parameters were set in the "defaults" portion of the request handler definition. Nothing else was being set in any other part of the request handler definition. Also, the raw query coming into the system contained ONLY the request handler specification...nothing else (all other parameters were being added by the request handler). Perhaps with this more complete information you might be able to recreate the issue. I would try right now but I'm under the gun for a release so I'll pass this information off to you. If you are still unsuccessful when we get this release out I'll see if I can tinker with it more and see what the determining factors are in the behavior we were seeing. Of course, other settings in the config files might be impacting this behavior...but one thing at a time I suppose. Thanks. Peter S. Lee -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: Tuesday, May 14, 2013 4:54 PM To: solr-user@lucene.apache.org Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1 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
