Regarding SOLR-112.patch, +1 on on the NamedList changes included from
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.