[
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: [email protected]
For additional commands, e-mail: [email protected]
