[ 
https://issues.apache.org/jira/browse/SOLR-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14329903#comment-14329903
 ] 

Shawn Heisey commented on SOLR-7127:
------------------------------------

bq. Should we try to deal with actions on the child clients that affect the 
parents (and all other created childs)

Calling methods in the child object that affect the parent is something that 
should be discouraged, even when it would work properly.  It might be a good 
idea to set a flag in the new constructor to indicate 'this' is a child client, 
and then for each method in CloudSolrClient, think about whether a child client 
should be able to use that method.  If not, throw an exception when the method 
is called and the child flag is set.  This is actually an argument in favor of 
returning SolrClient, because the abstract class won't have access to any of 
the implementation-specific methods without casting.

bq. Shouldn't {{public SolrClient getCollectionClient(String collection)}} 
return a CloudSolrClient instead?

For the reason just mentioned, as well as user code that is trying to be as 
generic as possible, I think that returning the abstract class is correct.  If 
we determine that any cloud-specific methods are safe to call on a child, and 
the dev is absolutely sure what they're dealing with, their code can cast the 
object to CloudSolrClient before calling those methods.

A quick glance says that there probably are some setter methods that should be 
allowed on child clients.


> Add method to CloudSolrClient to create per-collection clients
> --------------------------------------------------------------
>
>                 Key: SOLR-7127
>                 URL: https://issues.apache.org/jira/browse/SOLR-7127
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>            Priority: Minor
>         Attachments: SOLR-7127.patch, SOLR-7127.patch
>
>
> CloudSolrClient isn't thread-safe if you're making requests to multiple 
> collections, because defaultCollection is mutable.  This can be a pain if 
> you're trying to index into multiple collections from a single queue of 
> documents.
> This issue adds a .getCollectionClient(String) method to CloudSolrClient that 
> returns a child client directed at that collection.  Under the hood it's 
> another CloudSolrClient sharing it's resources with the parent client, but 
> with a separate default collection set.  The method returns a SolrClient, 
> however, so you can't then change the collection unless you explicitly cast 
> it.
> Sort of related to what I wanted to do on SOLR-6894, but this is more 
> focussed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to