[ 
https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-6365:
-----------------------------
    Description: 
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" paramSet="a"/>
  <requestHandler name="/dump2" class="DumpRequestHandler" paramSet="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}
 

  was:
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-->
<paramSet name="global" path="/**">
  <lst name="defaults">
     <str name="wt">json</str>
     <str name="df">_txt</str>
  </lst>
</paramSet>
{code}

other examples

{code:xml}
<paramSet 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>
  </paramSet>
  <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" paramSet="a"/>
  <requestHandler name="/dump2" class="DumpRequestHandler" paramSet="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}
 


> 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, 6.0
>
>         Attachments: 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" paramSet="a"/>
>   <requestHandler name="/dump2" class="DumpRequestHandler" paramSet="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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to