No results from solr search q = *:*

3
votes

Using solr 4.6.0 the following query returns no results:

solr/select/?q=*:*

But removing the q parameter returns all results, e.g.:

solr/select/

The request handler configuration contains the invarient:

<str name="q.alt">*:*</str>

Since q.alt is supposed to define the query when q is not provided, shouldn't the two queries be identical and return results? What are some possible reasons why the first form fails to return documents?

Additional Background

I'm using django-haystack 2.1.0 to actually connect to solr, the above queries are just the 'simplest failing case' in instances where empty queries are supplied. I've overloaded the haystack SearchForm to prevent empty queries returning empty result sets, and this worked with a much older version of solr and haystack 1.4.

Haystack "helpfully" populates q with *:* if no value is provided. Unfortunately, that's breaking the query as above. I could monkey-patch haystack, but I'd rather fix the problem in solr.

Note that queries with a populated (non-empty) q parameters work, e.g.

solr/select/?q=test

This will return results as expected.

1
solrdjango-haystack
what does a query to solr/select?q=*:* return? - jro
I think @jro is right, the / before the ? is in the way. - cheffe
It returns the same result (as you'd expect - the trailing slash doesn't change where the request is routed to. I'll add a little more detail. - Hamish

1 Answers

1
votes

Found the solution.

The search handler used DisMaxQParserPlugin (defType dismax):

The DisMaxQParserPlugin is designed to process simple user entered phrases (without heavy syntax)...

The *:* form of q was invalid for the DisMax parser, but the q.alt provides a fallback that is "..parsed by default using standard query parsing syntax..".

Changing the search handler plugin to ExtendedDisMax (defType edismax) fixes the problem.