[
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
