lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-6365) specify appends, defaults, invariants outside of the component
Date Sun, 09 Nov 2014 16:08:34 GMT


David Smiley commented on SOLR-6365:

Wow I'm late to this; I wish there was a way to signal particular JIRA issues as worthy of
more eyeballs.  

This feature reminds me of my feature-request "request handler inheritance" -- SOLR-3293.
 I understand the design goals of this new "initParams" feature and it's nice to see this
accomplished.  What I don't like about the newly added "initParams" feature is that it seems
redundant with request handlers themselves, and thus creates inevitable confusion as to what
takes precedence, and it's another parameter (not a big deal but something), and it's another
"thing" (the initParams) vs easily-grok'able feature of another "thing" (requestHandlers)
which already exist.  With request handler inheritance, you could have /select and /mainSearch
and /selectHighlight and /selectAutoSuggest or whatever.  Instead of making the parameter
set the configurable thing that is managed by ZooKeeper & a REST API, why not do this
for request handlers?

What I like about user-created requestHandlers is (a) Solr keeps stats on them separately,
and (b) they are easily distinguished in the URL.  Other things I like about them are achieved
in this patch, like changing a parameter relevant for some searches but not for others. 

> specify  appends, defaults, invariants outside of the component
> ---------------------------------------------------------------
>                 Key: SOLR-6365
>                 URL:
>             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, 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message