[
https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990669#comment-16990669
]
Jan Høydahl commented on SOLR-13936:
------------------------------------
Should not the old config-api and schema-api be deprecated too if we move both
of them to the cluster level? This workflow is already confusing enough:
* Create config "A" with collection "A" using it
* Create a collection "B" using configset "A"
* Call {{/solr/B/config}} (or {{/api/collection/B/config}}) to modify some
param for collection B
* BOOM, it also changes collection A
So by deprecating the (seemingly) per-collection APIs, this confusion goes away
too, instead of adding to the confusion. If we wanted to keep existing
collection level endpoints, I suppose those should instead be a thin layer
delegating to this new API, and only work for the special case where there is a
1:1 between collection and config and throw an error in all other cases.
> 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]
