On 3/11/2014 2:40 AM, rachun wrote:
> $q='macbook';
> $client = new SolrClient($config);
> $query = new SolrQuery();
> $query->setQuery($q);
> $query->addParam("shards.qt","/spell");
> $query->addParam("fl","product_name_th");
>
> $query_response = $client->query($query);
> $result = $query_response->getResponse();
<snip>
> ======================= Solr Log =================
>
> INFO - 2014-03-11 15:23:48.556; org.apache.solr.core.SolrCore;
> [collection1] webapp=/solr path=/select/
> params={fl=product_name_th&indent=on&shards.qt=/spell&start=0&q=macbook&wt=xml&rows=0&version=2.2}
> hits=4 status=0 QTime=2
> ==============================================
> At this log you can see it didn't go through my requestHandler named spell
> but when I try this
Your request went to the /select handler, not the /spell handler. The
shards.qt parameter controls where the request goes for *distributed*
queries, not standard queries.
I do not see a method in the documentation for the PHP library that sets
the request handler path. In SolrJ, this is the setRequestHandler method.
http://lucene.apache.org/solr/4_7_0/solr-solrj/org/apache/solr/client/solrj/SolrQuery.html#setRequestHandler%28java.lang.String%29
If you cannot set the request handler path to "/spell" instead of the
default "/select" then you would need to enable 'handleSelect' on the
<requestDispatcher> element in solrconfig.xml and send a "qt" parameter
set to "/spell". This capability was disabled in newer Solr releases
because it allows *any* request handler to be used with /select, even
/update, which is a potential exploit.
I would recommend asking for some help on whatever support resources are
available on the PHP client, and you may need to file a bug on that client.
Thanks,
Shawn
