[ https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188078#comment-17188078 ]
Noble Paul commented on SOLR-14680: ----------------------------------- Thanks for the review [~ab] {quote} why not use the standard getters, like getCollections(), getNodes() etc? {quote} The reason is that SolrCluster APIs are read-only APIs. if there is no corresponding setter method why bother with getX() {quote}It's a simpler, more scalable, and more transparent API than hiding the fetching & caching of values in a SimpleMap.{quote} List<String> is neither scalable nor transparent. SimpleMap is created for avoiding the API bloat of standard java interfaces. We do not need them. OTOH, SimpleMap lets you have a minimal set of methods which can be easily implemented. If you choose to actually use a HashMap or NamedList , you could do this easily {quote}SolrCluster.collections - this unnecessarily returns a map of SolrCollection, {quote} SolrCluster.collections does not return a Map, It returns a SimpleMap. neither is it required to be backed by a ConcurrentHashMap map. implementations can have more efficient ways of fetching it {quote}Again, what's wrong with standard getter names?{quote} same. read only APIs should not need a get prefix . > Provide simple interfaces to our concrete SolrCloud classes > ----------------------------------------------------------- > > Key: SOLR-14680 > URL: https://issues.apache.org/jira/browse/SOLR-14680 > Project: Solr > Issue Type: Improvement > Reporter: Noble Paul > Assignee: Noble Paul > Priority: Minor > Labels: clean-api > Time Spent: 10.5h > Remaining Estimate: 0h > > All our current implementations of SolrCloud such as > # ClusterState > # DocCollection > # Slice > # Replica > etc are concrete classes. Providing alternate implementations or wrappers is > extremely difficult. > SOLR-14613 is attempting to create such interfaces to make their sdk simpler > The objective is not to have a comprehensive set of methods in these > interfaces. We will start out with a subset of required interfaces. We > guarantee is that signatures of methods in these interfaces will not be > deleted/changed . But we may add more methods as and when it suits us -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org