lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-6365) specify appends, defaults, invariants outside of the component
Date Wed, 13 Aug 2014 09:54:12 GMT

    [ 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 9:52 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}

> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message