[
https://issues.apache.org/jira/browse/SOLR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466317
]
J.J. Larrea commented on SOLR-112:
----------------------------------
Regarding SOLR-112.patch, +1 on on the NamedList changes included from SOLR-107.
But I'm not sure a "blind" NamedList merging is going to accomplish what is
needed for an extends mechanism. As it stands that merges defaults into
defaults, invariants into invariants, appends into appends, along with any
other named lists that happen to be in the base list. That could stand some
further thought...
First, each existing SolrRequestHandler implementation (Standard and DisMax) in
init() now parses defaults, appends, and invariants sub-NamedLists into
individual SolrParams, and in handleRequest passes those and the request
SolrParams into SolrPluginUtils.setDefaults, which sets up a dynamic chain:
params => invariant-parms -> ((request-params -> default-params) +
appended-params)
such that invariant-params override request-params which override
default-params, with appended-params appended before the invariants override.
It's pretty cool.
The semantics of extended request handler configs may perhaps need to be
similar, with the extender's invariant params overriding any params in the
extendee, extendee invariants perhaps overriding non-invariants in the extender
(?), extender defaults overriding extendee defaults, and the appends
concatenated. I suppose given the above rule, it would simply be:
invariant-params => extender-invariants -> extendee-invariants
default-params => extender-defaults -> extendee defaults
appended-params => extender-appends + extendee-appends
(answering Hoss' question about what should happen if the keys are identical,
but not his other questions)
In some ways this would be neatest if implemented at the SolrParams level,
since there are nice classes like DefaultSolrParams and AppendedSolrParams,
implementing the -> and + operators I used above, respectively, and which have
informative toString()s. Unfortunately that's not so simple without serious
refactoring, since SolrRequestHandler.init takes a NamedList; as defined, a
handler could look for handler-specific initialization data in the NamedList,
and also doesn't necessarily need to parse and chain invariants, defaults, and
appends.
I suppose this would still work at the NamedList level, as long as there were a
flag for how to treat key conflicts (override vs. append), and that key were
set specifically for invariants and defaults, or just appends.
If done that way, it still leaves the question of whether the "merge" is done
statically by changing the NamedList, or dynamically by allowing NamedLists to
be chained. I suppose the only advantage of chaining is that toString() would
be more informative, and alone that's probably not sufficient to justify the
additional complexity.
Anyway, those are some ideas for discussion.
> 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
