[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466304
]
J.J. Larrea commented on SOLR-112:
----------------------------------
I'm sure you won't like your extemperaneous suggestion (foo/baz implicitly
extending foo with baz) once you get a chance to think about it, Hoss. :-)
The concern of efficiently structuring request handlers in solrconfig is quite
different from he concern of publishing them to the outside world. For
example, mightn't one set up the equivalent of an "abstract base class" request
config which has no value being invoked directly in a request, but has great
value as the root of a tree of request configs which will be invoked? And
similarly, shouldn't one be able to rearrange the internal configuration (e.g.
refactoring) without affecting an already "published" request syntax?
If it didn't break backwards compatibility, one could even consider having
separate arguments defining an internal name (used for extending) and an
external name (used for invoking), with either one being optional -- allowing
configs which are uninvokable but extendable, and vice versa. Or for better
backwards compatibility, one name could default to the other, but could be
explicitly overridden (potentially to the empty string) if so desired. I am
not advocating either of these approaches (simpler is perhaps better) as much
as using them to illustrate the separability of the concerns.
Does this make sense?
> 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
