I think you're using dismax, not edismax. edismax will take q=*:* just fine as
it handles all Lucene syntax queries also. dismax does not.
So, if you're using dismax and there is no actual query (but you want to get
facets), you set q.alt=*:* and omit q - that's entirely by design.
If there's a non-empty q parameter, q.alt is not considered so there shouldn't
be any issues with always have q.alt set if that's what you want.
Erik
On Nov 22, 2011, at 11:15 , Jeff Schmidt wrote:
> Hi Erik:
>
> It's not in the SolrJ library, but rather my use of it:
>
> In my application code:
>
> protected static final String SOLR_ALL_DOCS_QUERY = "*:*";
>
> /*
> * If no search terms provided, then return all neighbors.
> * Results are to be returned in neighbor symbol alphabetical order.
> */
>
> if (searchTerms == null) {
> searchTerms = SOLR_ALL_DOCS_QUERY;
> nodeQuery.addSortField("n_name", SolrQuery.ORDER.asc);
> }
>
> So, if no user search terms are provided, I search all documents (there are
> other fqs in effect) and return them in name order.
>
> That worked just fine. Then I read more about [e]dismax, and went and
> configured:
>
> <str name="q.alt">*:*</str>
>
> Then I would get zero results. It's not a SolrJ issue though, as this
> request in my browser also resulted in zero results:
>
> http://localhost:8091/solr/ing-content/select/?qt=partner-tmo&fq=type%3Anode&fq=n_neighborof_id%3AING\:afa&q=*:*&rows=5&facet=true&facet.mincount=1&facet.field=n_neighborof_processExact&facet.field=n_neighborof_edge_type
>
> That was due to the q=*:*. Once I set, say, q=cancer, I got results. So I
> guess this is a [e]dismax thing? (partner-tmo is the name of my request
> handler).
>
> I solved my problem by net setting *:* in my application, and left q.alt=*:*
> in place.
>
> Hope this helps. Again, this is stock Solr 3.4.0, running the Apache war
> under Tomcat 6.
>
> Jeff
>
> On Nov 22, 2011, at 8:05 AM, Erik Hatcher wrote:
>
>>
>> On Nov 22, 2011, at 09:55 , Jeff Schmidt wrote:
>>> When using [e]dismax, does configuring q.alt=*:* and not specifying q
>>> affect the performance/caching in any way?
>>
>> No different than using q=*:* with the "lucene" query parser.
>> MatchAllDocsQuery is possibly the fastest query out there! (it simply
>> matches documents in index order, all scores are 1.0)
>>
>>> As a side note, a while back I configured q.alt=*:*, and the application
>>> (via SolrJ) still set q=*:* if no user input was provided (faceting). With
>>> both of them set that way, I got zero results. (Solr 3.4.0) Interesting.
>>
>> Ouch. Really? I don't see in the code (looking at my trunk checkout) where
>> there's any *:* used in the SolrJ library. Can you provide some details on
>> how you used SolrJ? It'd be good to track this down as that seems like a
>> bug to me.
>>
>> Erik
>>
>>
>>>
>>> Thanks,
>>>
>>> Jeff
>>>
>>> On Nov 22, 2011, at 7:06 AM, Erik Hatcher wrote:
>>>
>>>> If all you're doing is filtering (browsing by facets perhaps), it's
>>>> perfectly fine to have q=*:*. MatchAllDocsQuery is fast (and would be
>>>> cached anyway), so use *:* as appropriate without worries.
>>>>
>>>> Erik
>>>>
>>>>
>>>>
>>>> On Nov 22, 2011, at 07:18 , pravesh wrote:
>>>>
>>>>> Usually,
>>>>>
>>>>> Use the 'q' parameter to search for the free text values entered by the
>>>>> users (where you might want to parse the query and/or apply
>>>>> boosting/phrase-sloppy, minimum match,tie etc )
>>>>>
>>>>> Use the 'fq' to limit the searches to certain criterias like location,
>>>>> date-ranges etc.
>>>>>
>>>>> Also, avoid using the q=*:* as it implicitly translates to
>>>>> matchalldocsquery
>>>>>
>>>>> Regds
>>>>> Pravesh
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://lucene.472066.n3.nabble.com/how-to-make-effective-search-with-fq-and-q-params-tp3527217p3527535.html
>>>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Jeff Schmidt
>>> 535 Consulting
>>> j...@535consulting.com
>>> http://www.535consulting.com
>>> (650) 423-1068
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Jeff Schmidt
> 535 Consulting
> j...@535consulting.com
> http://www.535consulting.com
> (650) 423-1068
>
>
>
>
>
>
>
>
>
