gerlowskija commented on code in PR #3238:
URL: https://github.com/apache/solr/pull/3238#discussion_r2001372713
##########
solr/solrj/src/java/org/apache/solr/client/solrj/SolrRequest.java:
##########
@@ -210,6 +236,16 @@ public boolean requiresCollection() {
return false;
}
+ /**
+ * Indicates if clients should make attempts to route this request to a
shard leader, overriding
+ * typical client routing preferences for requests. Defaults to true.
+ *
+ * @see CloudSolrClient#isUpdatesToLeaders
+ */
+ public boolean shouldSendToLeaders() {
Review Comment:
> Any way, I don't think it makes sense for this to be on SolrRequest
generally.
@dsmiley is this more "sharing your thoughts", or do you want Jude to
address this in some way? Just want to double-check so there's no ambiguity.
I agree with you that UpdateRequest should probably re-use
`shards.preference` instead of offering additional methods to impact routing.
(Or perhaps - maybe UpdateRequest offers a few syntax-sugar methods to set
common preferences, but those operate by modifying `shards.preference` rather
than maintaining a separate boolean?).......but all of that feels out of scope
in a PR that was proposed initially as a refactor?
If you feel strongly about the method being out of place on SolrRequest,
maybe the best approach for now is to file a follow-up ticket, and to hold off
touching the UpdateRequest stuff at all in this PR?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
