murblanc commented on PR #2459: URL: https://github.com/apache/solr/pull/2459#issuecomment-2117113044
> Separately, I wonder if we make it too easy to loop the state of every collection. I'm looking at `Cluster` added by @murblanc which contains not only an `Iterator<SolrCollection> iterator();` method, but also `Iterable<SolrCollection> collections();` to make it that much easier. Instead, let's just have a method to list collection names. Then if the caller is hell bent on looping everything in the cluster, it's going to be that much more obvious to that code that it's looking up collection info for each and every one. `org.apache.solr.cluster.Cluster` is made to present the internal cluster abstraction to plugin writers in order to decouple plugins from the internal implementation (so we can change the abstractions without breaking plugins). The existing internal cluster abstraction does allow listing all collections, as does the Collection API BTW. Instead of shooting the messenger (`org.apache.solr.cluster.Cluster`) we could reconsider if listing all collections in general makes sense. Obviously listing all collections does not scale, but most SolrCloud deployments do not have such scaling issues. If we do think that listing all collections is useful (which you seem to agree to given the proposal to return all names), I'd rather have the API we offer to plugin writers be easy to use. Returning names and forcing the caller to go fetch the collection one by one is not convenient. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
