[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467712
]
Hoss Man commented on SOLR-112:
-------------------------------
I think you're dead on JJ ... any generic NamedList merging won't neccessarily
do "the right thing" in all cases when talking about RequestHandler init args
-- very special logic would need to be used to deal with the
defaults/appends/invarients in a logical manner, and that logic may not be bale
to take into account other init params that other RequestHandlers (subclasses
of the core ones perhaps) might add.
a cleaner way to deal with this might just be to have the individual
RequestHandlers manage this themselves -- using
SolrCore.getRequestHandler(String) and protected methods they explicitly
support to allow other instances to get access to their SolrParams.
ie...
<requestHandler name="search/products/all" class="solr.DisMaxRequestHandler" >
<lst name="defaults">
<str name="facet.field">category</str>
<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>
</requestHandler>
<requestHandler name="search/products/instock"
class="solr.DisMaxRequestHandler">
<str name="extends">search/products/all</str>
<lst name="defaults">
<str name="facet.query">price:[0 TO 100]</str>
<str name="facet.query">price:[100 TO *]</str>
</lst>
<lst name="appends">
<str name="fq">inStock:true</str>
</lst>
</requestHandler>
...where DisMaxRequestHandler (or most likely teh new Base class Ryan has
written) has methods like...
protected SolrParams getDefaults()
protected SolrParams getInvarients()
protected SolrParams getAppends()
...and the init method looks for an "extends" arg, if it's there fetches it
from the SolrCore, tests it's class and casts it, then calls the methods above
and builds up it's own SolrParams usign a combination of those and the ones
explicitly specified in it's config.
> 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.
-
You can reply to this email to add a comment to the issue online.
