[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466308
]
J.J. Larrea commented on SOLR-112:
----------------------------------
Re foo vs. /foo:
I think of the SolrServlet as being just one way to invoke the request
dispatcher. One could for example write a SOAP or other RPC message receiver
which called a method something like handleRequest(String reqName,
SolrQueryRequest req, SolrQueryResponse rsp)*1*. So I wouldn't want to bind
the request invocation syntax too tightly to a URL-based mechanism for
invocation.
Similarly, I think of allowing slashes in request handler names as merely a
convention; it could be "search.products.instock" or "search-products-instock"
just as easily. Of course, it is advantageous for the handler name to be
RFC1738-compliant (as those examples both are) so the pathInfo can be used to
set the name, as we all like, e.g.
http://localhost:8989/solr/select/search-products-instock
What your suggestion comes down to, Ryan, is whether the pathInfo-parsed
request adds a leading / slash to the request name, or not. If it does it
forces URL syntax into the request-naming space, and while that won't
particularly hurt anything I'm not sure it buys anything either... Why should
a SOLR configurer need to make an explicit gesture to indicate they want to use
the more "modern" pathInfo-based invocation style rather than the older qt=
invocation style? And shouldn't the request handler definition be either
agnostic as to the request method (GET, POST, pathINFO, qt=, SOAP, direct API
call, ...) or else have access to a more comprehensive mechanism for filtering
which methods they respond to?
*1* (I haven't yet had a chance to catch up on the voluminous SOLR-104
discussion so this may not be the currently contemplated syntax, but hopefully
my argument for potentially supporting non-URL-based invokers still holds.)
> Hierarchical Handler Config
> ---------------------------
>
> Key: SOLR-112
> URL: https://issues.apache.org/jira/browse/SOLR-112
> Project: Solr
> Issue Type: Improvement
> Components: update
> Affects Versions: 1.2
> Reporter: Ryan McKinley
> Priority: Minor
> Fix For: 1.2
>
> Attachments: SOLR-112.patch
>
>
> From J.J. Larrea on SOLR-104
> 2. What would make this even more powerful would be the ability to "subclass"
> (meaning refine and/or extend) request handler configs: If the requestHandler
> element allowed an attribute extends="<another-requesthandler-name>" and
> chained the SolrParams, then one could do something like:
> <requestHandler name="search/products/all"
> class="solr.DisMaxRequestHandler" >
> <lst name="defaults">
> <float name="tie">0.01</float>
> <str name="qf">
> text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
> </str>
> ... much more, per the "dismax" example in the sample solrconfig.xml ...
> </requestHandler>
> ... and replacing the "partitioned" example ...
> <requestHandler name="search/products/instock"
> extends="search/products/all" >
> <lst name="appends">
> <str name="fq">inStock:true</str>
> </lst>
> </requestHandler>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
