[
https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14191310#comment-14191310
]
Erick Erickson commented on SOLR-6365:
--------------------------------------
I haven't thought about it too deeply. Off the top of my head, having
locally-defined parameters override the initParams seems best. Say you want to
have a different default search field for the /query handler and the /select
handler, but want all the other params to remain the same. You could call out
the initParams, but add a single param in the "defaults" section of one of the
handlers. Not entirely sure it's a valid example, but you see where it's going.
I don't feel super-strongly about either approach. I come down somewhat on the
side of the individual request handlers being able to override the initParams
on the basis that inevitably there'll be a questions like "I just want to
change one thing, why do I have to define a whole new initParams node?".
I'll argue though that we should make it harder to fall into the trap I just
fell into; taking my experience with solrconfig.xml and thinking I knew what I
was doing. We could accomplish this just by taking all the defaults, invariants
etc out of the individual request handlers. This would at least cause some
head-scratching, perhaps with a comment in solrconfig.xml directing them to the
initParams (and possibly this JIRA or the Reference Guide?) to let people know
where to look for all of the details. I flat guarantee that people will
copy/paste their old defaults (& etc) sections from old solrconfig files to the
new one and be puzzled if we don't direct their attention appropriately.
> specify appends, defaults, invariants outside of the component
> ---------------------------------------------------------------
>
> Key: SOLR-6365
> URL: https://issues.apache.org/jira/browse/SOLR-6365
> Project: Solr
> Issue Type: Improvement
> Reporter: Noble Paul
> Assignee: Noble Paul
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6365-crappy-test.patch, SOLR-6365.patch,
> SOLR-6365.patch
>
>
> The components are configured in solrconfig.xml mostly for specifying these
> extra parameters. If we separate these out, we can avoid specifying the
> components altogether and make solrconfig much simpler. Eventually we want
> users to see all functions as paths instead of components and control these
> params from outside , through an API and persisted in ZK
> objectives :
> * define standard components implicitly and let users override some params
> only
> * reuse standard params across components
> * define multiple param sets and mix and match these params at request time
> example
> {code:xml}
> <!-- use json for all paths and _txt as the default search field-->
> <initParams name="global" path="/**">
> <lst name="defaults">
> <str name="wt">json</str>
> <str name="df">_txt</str>
> </lst>
> </initParams>
> {code}
> other examples
> {code:xml}
> <initParams name="a" path="/dump3,/root/*,/root1/**">
> <lst name="defaults">
> <str name="a">A</str>
> </lst>
> <lst name="invariants">
> <str name="b">B</str>
> </lst>
> <lst name="appends">
> <str name="c">C</str>
> </lst>
> </initParams>
> <requestHandler name="/dump3" class="DumpRequestHandler"/>
> <requestHandler name="/dump4" class="DumpRequestHandler"/>
> <requestHandler name="/root/dump5" class="DumpRequestHandler"/>
> <requestHandler name="/root1/anotherlevel/dump6"
> class="DumpRequestHandler"/>
> <requestHandler name="/dump1" class="DumpRequestHandler" initParams="a"/>
> <requestHandler name="/dump2" class="DumpRequestHandler" initParams="a">
> <lst name="defaults">
> <str name="a">A1</str>
> </lst>
> <lst name="invariants">
> <str name="b">B1</str>
> </lst>
> <lst name="appends">
> <str name="c">C1</str>
> </lst>
> </requestHandler>
> {code}
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
