[
https://issues.apache.org/jira/browse/SOLR-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17655154#comment-17655154
]
Jan Høydahl commented on SOLR-10466:
------------------------------------
We now have [63
methods|https://github.com/apache/solr/blob/main/solr/solrj/src/java/org/apache/solr/client/solrj/SolrClient.java]
in our SolrClient. What if we boiled it down to these 8 instead, requiring the
caller to supply the appropirate Request object:
{code:java}
UpdateResponse update(UpdateRequest req)
UpdateResponse commit(CommitRequest req, CommitFlag... flags)
UpdateResponse optimize(OptimizeRequest req, CommitFlag... flags)
UpdateResponse rollback(RollbackRequest req)
QueryResponse query(QueryRequest req)
QueryResponse queryAndStreamResponse(QueryRequest req,
StreamingResponseCallback callback)
SolrPingResponse ping(SolrPing req)
SolrDocument getById(GetByIdRequest req) {code}
An update would look something like this
{code:java}
client.update(new
UpdateRequest("myColl").add(myInputDocument).setCommitWithin(1000));{code}
Then, the various Request objects would require a "collection" argument in the
constructor, and the client can construct correct URL based on that.
CloudSolrClient can still be immutable, since it won't have any default
collection.
> 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: 4h
> 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
