Thanks, Erik. I'm moving on to edismax, and will set q.alt=*:* and not specify
q if no user provided terms.
Take it easy,
Jeff
On Nov 22, 2011, at 11:53 AM, Erik Hatcher wrote:
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
--
Jeff Schmidt
535 Consulting
j...@535consulting.com
http://www.535consulting.com
(650) 423-1068
