[
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, 2:41 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 .java.util.Map has >40
methods. and SimpleMap can be implemented with just 2 methods. SimpleMap
implemenaton can be easily wrapped and backed by almost any data structures .
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 start using the use
generic interfaces & fix the problems. This is a classic catch 22. How do you
use new interfaces if they do not exist in the first place?
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 .
{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.
> 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
