[
https://issues.apache.org/jira/browse/SOLR-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16991593#comment-16991593
]
Jason Gerlowski commented on SOLR-13936:
----------------------------------------
bq. sharing configsets is a very niche feature and I don't think many users are
affected at the moment
Without hard numbers this is all just guesswork, so disclaimer there, but I'd
imagine many many users use the {{_default}} configset for multiple
collections. Or for all of their collections.
bq. I'm not happy with just simply adding more API surface without taking
anything away.
I agree with Jan in this particular case. It's confusing to users to have two
APIs that do the same job, and it will be a net add to our maintenance burden
as a project.
bq. It would be absolutely terrible if a user created collection
"mycollection", but had to invoke config API on
`/api/cluster/configset/mycollection.AUTOCREATED`. (A user would be left
wondering, what is a "configset" and why this "AUTOCREATED" suffix etc.).
I hear your concern about confusing users, Ishan. That said, I have to imagine
that if a user knows enough about collection configuration to tweak some
properties, then they are also aware that those properties belong to a grouping
called a configset. And in the cases where users don't know this, they're
ill-served by it e.g. they modify a dynamic field in 'N' collections instead of
just in their intended one. While we currently allow sharing of configsets in
the way we do, I think obscuring them is trappy and dangerous. That is one
benefit of the new API - users are prompted to realized that configsets are
independent of collections and might be shared. If we add this new API I'd
rather not see it's benefit undercut by keeping the old one around.
I don't want to bloat the issue, but if there's continued disagreement on
whether the old APIs are worth keeping, then maybe a SIP is warranted. The
configset behavior (preexisting this jira) is murky enough currently that it
might be worth clarifying.
> 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]
