[
https://issues.apache.org/jira/browse/SOLR-6365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14094225#comment-14094225
]
Noble Paul edited comment on SOLR-6365 at 8/12/14 4:06 PM:
-----------------------------------------------------------
bq.that's not even valid XML (bare &)
yeah, you are right, according to xml standards it is not. But all parsers
accept that . But that is besides the point
bq.and what does it even mean to say that you want to set some defaults and
invariants on {{/some-other-path/*}} if you don't configure any type of
information about what handler {{/some-other-path/}} uses?
Yes, Looking from a user's point of view. They don't really think about the
solr components. They assume that a given path , say {{/update}}, has certain
capabilities and accepts certain parameters . For them it is not a component ,
it is just an API end point. Yes, you can of course specify wrong parameters
which you are free to do even now. I'm not saying we will take away all
configuration from solrconfig.xml . It is mainly for the fixed paths.
The other use case this addresses is our REST APIs. It is managed completely
outside of solrconfig.xml and there is no way to specify params .
bq.how would this kind of syntax help with "...we can avoid specifying the
components altogether and make solrconfig much simpler." ?
I'm thinking of fixing certain paths and avoiding certain common definitions in
the xml file. We should make it fixed saying that certain paths and their
parameters are fixed say {{/select}} , {{/update}}, {{/admin/*}} etc. All I
should be able to do is set params
In the current design it is impossible to have global level configurations
which spans multiple components , say {{wt=json}} or {{df=text}} for all paths.
bq.So I guess you're thinking of some higher-level problem that this is part
of, what is that problem? A REST API for solrconfig?
Yes, you are right , this issue is not addressing that use case, But it becomes
much simpler to provide an API to modify params than the entire components.
Most often the usecase is about changing the params
was (Author: noble.paul):
bq.that's not even valid XML (bare &)
yeah, you are right, according to xml standards it is not. But all parsers
accept that . But that is besides the point
bq.and what does it even mean to say that you want to set some defaults and
invariants on {{/some-other-path/*}} if you don't configure any type of
information about what handler {{/some-other-path/}}* uses?
Yes, Looking from a user's point of view. They don't really think about the
solr components. They assume that a given path , say {{/update}}, has certain
capabilities and accepts certain parameters . For them it is not a component ,
it is just an API end point. Yes, you can of course specify wrong parameters
which you are free to do even now. I'm not saying we will take away all
configuration from solrconfig.xml . It is mainly for the fixed paths.
The other use case this addresses is our REST APIs. It is managed completely
outside of solrconfig.xml and there is no way to specify params .
bq.how would this kind of syntax help with "...we can avoid specifying the
components altogether and make solrconfig much simpler." ?
I'm thinking of fixing certain paths and avoiding certain common definitions in
the xml file. We should make it fixed saying that certain paths and their
parameters are fixed say {{/select}} , {{/update}}, {{/admin/*}} etc. All I
should be able to do is set params
In the current design it is impossible to have global level configurations
which spans multiple components , say {{wt==json}} for all paths.
bq.So I guess you're thinking of some higher-level problem that this is part
of, what is that problem? A REST API for solrconfig?
Yes, you are right , this issue is not addressing that use case, But it becomes
much simpler to provide an API to modify params than the entire components.
Most often the usecase is about changing the params
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
