[ https://issues.apache.org/jira/browse/SOLR-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653312#comment-17653312 ]
Eric Pugh commented on SOLR-10466: ---------------------------------- Do we need a online design session to figure out what to do with this setting? It seems like our SolrClient is working at cross purposes... Is it a generic client that can interact with any collection, and therefore you pass in collection name, or is it tied to a single collection? Or is it even a generic client to work with all end points of Solr? I'm honestly not really sure either way... And if you generalize a SolrClient to doing more then just inserting docs and making queries, but to doing other operations against solr, like admin apis calls, or the functions, then maybe having the default collection makes even less sense? SolrClientV2.java ???? Having gone through migrating setDefaultCollection to the builder, and migrating tests, it basically feels like actually more of a convenience thing than a true "issue". Basically, if you want to work with multiple collections, and you don't want to constantly pass in the collectionName, then you just have multiple collections. Or, just pass in the $%#$ collection name on your methods ;-). > setDefaultCollection should be deprecated in favor of SolrClientBuilder > methods > ------------------------------------------------------------------------------- > > Key: SOLR-10466 > URL: https://issues.apache.org/jira/browse/SOLR-10466 > Project: Solr > Issue Type: Sub-task > Components: SolrJ > Reporter: Jason Gerlowski > Assignee: Eric Pugh > Priority: Minor > Fix For: 7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Now that builders are in place for {{SolrClients}}, the setters used in each > {{SolrClient}} can be deprecated, and their functionality moved over to the > Builders. This change brings a few benefits: > - unifies {{SolrClient}} configuration under the new Builders. It'll be nice > to have all the knobs, and levers used to tweak {{SolrClient}}s available in > a single place (the Builders). > - reduces {{SolrClient}} thread-safety concerns. Currently, clients are > mutable. Using some {{SolrClient}} setters can result in erratic and "trappy" > behavior when the clients are used across multiple threads. > This subtask endeavors to change this behavior for the > {{setDefaultCollection}} setter on all {{SolrClient}} implementations. -- 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