Missing query can cause Solr to ignore the request

Seems like a reasonable check to do, and a simple way to handle the situation. Any suggestions as to how this can be tested?

That's great, thanks! (for the follow-up and the patch)

Just FYI, versions of Sarnia prior to our recent work wouldn't have had this problem. It was the removal of the hard-coded requestHandler names that caused certain configurations to not return results without a search. You'll see in that comment that I noted the standard requestHandler would not return any results by default because the $call_args['query'] = '*:*' was removed.

I didn't really consider it a problem because I figured people could adjust their requestHandler config to return all results by default. This makes me wonder what is better (although I realize the patch has already been committed). Is it better to hard-code the module to return all results by default to avoid any confusion that might be caused by empty result sets? On the other hand, is there a use case that we're preventing where someone might not want all records to be returned? Therefore, is it more responsible to leave the configuration up to the admin in their Solr config files? I don't know the answer to those questions. My instinct says "we probably should leave that up to the Solr config." At least that is mitigated by the fact that you can configure Views to not display anything if a search has not been performed, so there is an easy workaround.

Anyway, configuring the module to use the standard requestHandler should be the easy way to test if this patch works. Use the Drupal Common Config files, set the Sarnia server config requestHandler to "standard", then test to see if it returns no results by default (without a search being performed) before the patch and then see if it returns results afterward.

dcam: I guess that's what dev version builds are for :)

I kind of like the idea of having an interface for a default query. When this patch was first submitted, the thought ran through my mind that making an assumption on the default query behavior might not be the best thing, but there is also the case where one might not be in control of the source Solr core, and might have to mitigate against it.

Here's a proposed patch that puts an interface to the default query parameter in the Sarnia server settings.

Re-rolling patch in #17 to use Unix-style line endings.

Patch in message #20 (mis-labeled as #18) returned an error, when re-saving a Sarnia index (and not a server entity). This patch remedies that error.

Fixed paths in #21 and re-rolled, in case some people had trouble applying.

Committing the patch in #23 to dev. Adding the default query allowed a lot of the demo cores that come with Solr to work and display Views, as tlyngej noted with the Solr mail demo core. It had been a stretch goal of mine to get the "techproducts" db DataImportHandler demo working that was included with Solr, and I was able to get it displaying Views properly with this series of patches. #23 incorporates the originally submitted patch, plus adds a UI to the Sarnia server config to override the default query, if that is ever needed.