[ 
https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991010#comment-16991010
 ] 

Jan Høydahl commented on SOLR-13936:
------------------------------------

I'm thinking perhaps this issue right here is a good candidate as SIP-1 over at 
https://cwiki.apache.org/confluence/display/SOLR/Solr+Improvement+Proposals ? 
Then we could end up with a clear design proposal for fixing this mess, what 
should be deprecated and what APIs to support. I'm not happy with just simply 
adding more API surface without taking anything away.

If I could choose I'd go in the direction of treating configsets as config 
*templates*, and once you create a collection using a certain configset 
(template), that config is *copied* into a collection specific config with the 
same name as the collection, which is edited through *today's* config API. 
That's more or less how it works in master/slave mode already. That would 
maintain todays flexibility ut remove much of the confusion. In such a world it 
could make sense to add a configset edit API and keep today's collection level 
APIs. Collection specific configs would live in zk {{/configs}} with same name 
as collection, while configsets perhaps should get their own znode? Such a 
breaking change should of course wait until a major release.

> Schema/Config endpoints to modify configset with no core/collection
> -------------------------------------------------------------------
>
>                 Key: SOLR-13936
>                 URL: https://issues.apache.org/jira/browse/SOLR-13936
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: config-api
>            Reporter: Apoorv Bhawsar
>            Priority: Minor
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> All schema/config configurations should work even in cases where a collection 
> is not associated with them
>  This jira will involve
>  1. Refactoring existing handler/manager to work without {{SolrCore}}
>  2. Adding {{/api/cluster}} endpoints to support such modifications
>  Endpoints -
>  * {{/api/cluster/configset/\{name}/schema}}
>  * {{/ap/cluster/configset/\{name}/config}}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to