[ https://issues.apache.org/jira/browse/SOLR-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617776#comment-17617776 ]
ASF subversion and git services commented on SOLR-16368: -------------------------------------------------------- Commit 909341b8e9ba4eb33c4946dec6b340c8c3ffaa8a in solr's branch refs/heads/branch_9x from Eric Pugh [ https://gitbox.apache.org/repos/asf?p=solr.git;h=909341b8e9b ] backport SOLR-16368 > Refactoring: Use SolrClient type instead of overly specific subclasses > ---------------------------------------------------------------------- > > Key: SOLR-16368 > URL: https://issues.apache.org/jira/browse/SOLR-16368 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Reporter: David Smiley > Assignee: Eric Pugh > Priority: Minor > Time Spent: 5h 10m > Remaining Estimate: 0h > > There are many references to a specific SolrClient subclass that could simply > refer to SolrClient generally, or perhaps CloudSolrClient. This impedes > switching/migrating to different SolrClient implementations. A similar > example: we know it's a bad practice to declare a List as ArrayList even when > it is one; the idea here with SolrClient is the same. > And furthermore, often times "var solrClient = ..." (or even "var solr = > ...") is totally adequate in the Solr codebase within a method because the > variable name adequately communicates the type. These sorts of changes > should happen first, and then weaken type references in APIs. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org