[
https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14095230#comment-14095230
]
Noble Paul edited comment on SOLR-6365 at 8/13/14 11:22 AM:
------------------------------------------------------------
There are clearly two aspects to this ticket.
First and the important one is the ability to define params(or paramsets )
outside of components . Reference them by name in request/component config, or
assign them to paths etc. I see params as just name-values used in requests or
component initialization and not as integral parts of components. While, we
the devs ,see Solr as a system of carefully assembled components as per an xml
configuration (solrconfig.xml) , the average user sees Solr as a server which
supports a bunch of APIs (of http paths) . I don't see a reason why a certain
component should not be there as long as it is not consuming resources (lazy
loading) or is a security hole (Tika?) . So , all the paths are available all
the time and fixed (unless a user explicitly overrides it) . Once we separate
out the params we have better ways to configure them via REST apis or in a
zookeeper node .
The second part is the syntax and we should move towards a syntax that is more
palatable to the 'new generation' and not just the old timers.I'm sure we can
arrive at a reasonably clean way to put them in solrconfig.xml and we should
choose one that is best for our users . I see no reason to have type info
(str,int,bool etc) in configuration when http has no ways to support them . So,
all components will have to assume that all variables are strings and parse
them accordingly .
compare the following
{code:xml}
<!-- use json for all paths and _txt as the default search field-->
<params id="global" path="/**" defaults="wt:'json',df:'_txt'" />
{code}
or
{code:xml}
<!-- use json for all paths and _txt as the default search field-->
<params id="global" path="/**">
<lst name="defaults">
<str name="wt">json</str>
<str name="df"_txt</str>
</lst>
</params>
{code}
Please suggest other options if you can think of
was (Author: noble.paul):
There are clearly two aspects to this ticket.
First and the important one is the ability to define params(or paramsets )
outside of components . Reference them by name in request/component config, or
assign them to paths etc. I see params as just name-values used in requests or
component initialization and not as integral parts of components. While, we
the devs ,see Solr as a system of carefully assembled components as per an xml
configuration (solrconfig.xml) , the average user sees Solr as a server which
supports a bunch of APIs (of http paths) . I don't see a reason why a certain
component should not be there as long as it is not consuming resources (lazy
loading) or is a security hole (Tika?) . So , all the paths are available all
the time and fixed (unless a user explicitly overrides it) . Once we separate
out the params we have better ways to configure them via REST apis or in a
zookeeper node .
The second part is the syntax and we should move towards a syntax that is more
palatable to the 'new generation' and not just the old timers.I'm sure we can
arrive at a reasonably clean way to put them in solrconfig.xml and we should
choose one that is best for our users . I see no reason to have type info
(str,int,bool etc) in configuration when http has no ways to support them . So,
all components will have to assume that all variables are strings and parse
them accordingly .
compare the following
{code:xml}
<!-- use json for all paths and _txt as the default search field-->
<params id="global" path="/**" defaults="wt:json,df:_txt" />
{code}
or
{code:xml}
<!-- use json for all paths and _txt as the default search field-->
<params id="global" path="/**">
<lst name="defaults">
<str name="wt">json</str>
<str name="df"_txt</str>
</lst>
</params>
{code}
Please suggest other options if you can think of
> 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
>
> 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 funtions as paths instead of components and control these
> params from outside , through an API and persisted in ZK
> example
> {code:xml}
> <!-- these are top level tags not specified inside any components -->
> <params path="/dataimport" defaults="config=data-config.xml"/>
> <params path="/update/*" defaults="wt=json"/>
> <params path="/some-other-path/*" defaults="a=b&c=d&e=f" invariants="x=y"
> appends="i=j"/>
> <!-- use json for all paths and _txt as the default search field-->
> <params path="/**" defaults="wt=json&df=_txt" />
> {code}
> The idea is to use the parameters in the same format as we pass in the http
> request and eliminate specifying our default components in solrconfig.xml
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
