You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Noble Paul (JIRA)" <ji...@apache.org> on 2014/08/12 18:07:13 UTC
[jira] [Comment Edited] (SOLR-6365) specify appends, defaults,
invariants outside of the component
[ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org