You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Noble Paul (Jira)" <ji...@apache.org> on 2020/09/01 01:15:00 UTC
[jira] [Comment Edited] (SOLR-14680) Provide simple interfaces to
our concrete SolrCloud classes
[ https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17188078#comment-17188078 ]
Noble Paul edited comment on SOLR-14680 at 9/1/20, 1:14 AM:
------------------------------------------------------------
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 .
{quote}And finally, my main objection is that this API currently doesn't do anything, it's totally disconnected and there's no proof (as in working usage) that it's suitable or sufficient to be actually used for anything practical.{quote}
This is a valid concern. We need to get to a place where we can use generic interfaces.
was (Author: noble.paul):
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-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org