[
https://issues.apache.org/jira/browse/SOLR-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517023#comment-16517023
]
Varun Thacker commented on SOLR-11654:
--------------------------------------
Wow! I was surprised when I saw 10 add methods already in SolrClient . How do
our users even use our APIs :/
Maybe food for another Jira : If we need 10+ add methods and the fact that the
UpdateRequest is public meaning they could do this by stiching it together
themselves anyways doesn't sound right at all. Happy to discuss and contribute
in the right Jira if others feel the same way.
But for the scope of this Jira maybe it's not the worst thing adding a couple
of more methods as well? I guess if we just use UpdateRequest we wouldn't need
this but that depends on Gus and you on how much ease does this add to docs vs
directly using UpdateRequest ?
> TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection should route to
> the ideal shard
> --------------------------------------------------------------------------------------------
>
> Key: SOLR-11654
> URL: https://issues.apache.org/jira/browse/SOLR-11654
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Components: SolrCloud
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Major
> Attachments: SOLR-11654.patch, SOLR-11654.patch, SOLR-11654.patch
>
>
> {{TimePartitionedUpdateProcessor.lookupShardLeaderOfCollection}} looks up the
> Shard/Slice to talk to for the given collection. It currently picks the
> first active Shard/Slice but it has a TODO to route to the ideal one based on
> the router configuration of the target collection. There is similar code in
> CloudSolrClient & DistributedUpdateProcessor that should probably be
> refactored/standardized so that we don't have to repeat this logic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
