[
https://issues.apache.org/jira/browse/SOLR-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14350518#comment-14350518
]
Shawn Heisey commented on SOLR-7201:
------------------------------------
bq. And forcing people to add a null parameter to their code all over the place
is just ugly.
I agree with this, but I think the suggested forward migration path should be a
situation where only the new methods are used, and every call will include a
non-null string for collection. Leaving out setDefaultCollection would
encourage this as well, so that sounds like a good plan. I think perhaps we
should deprecate setDefaultCollection in CloudSolrClient as well, since it is
not threadsafe and new functionality removes the need for it.
Deprecation gives the developer a instant clue that they are not using the
class in the way that the authors intended. We can describe the design intent
in the javadoc ... but deprecation gives an IDE user an immediate indicator
that they should read that javadoc and change their code.
I'm excited about this new functionality. I'll be able to change code that
currently creates sixty HttpSolrServer objects (56 for talking to individual
cores, four for CoreAdminRequest functionality to the servers) so it only
creates four HttpSolrClient objects.
> Implement multicore handling on HttpSolrClient
> ----------------------------------------------
>
> Key: SOLR-7201
> URL: https://issues.apache.org/jira/browse/SOLR-7201
> Project: Solr
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Minor
> Attachments: SOLR-7201.patch
>
>
> Now that SOLR-7155 has added a collection parameter to the various SolrClient
> methods, we can let HttpSolrClient use it to allow easier multicore handling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
