[
https://issues.apache.org/jira/browse/SOLR-11654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16517065#comment-16517065
]
David Smiley commented on SOLR-11654:
-------------------------------------
It's not a great ease to add this to SolrClient admittedly (IMO)... and it's
easy enough to add a utility method on this test which does this equivalent
logic. I was about to point out that UpdateRequest's setter methods return
"this" which can make usage even more compact but this isn't done uniformly
here (which is sloppy) – setParams doesn't.
Any way I guess we'll leave SolrClient alone. Thanks for your input Varun.
Yes it's a shame there are so many darned overloaded methods... I think it's a
large part due to the optional "collection" parameter which like doubles the
methods! I've been bitten several times writing SolrJ code that doesn't use
the right overloaded version (forgot to specify collection). I think for 8.0,
*either* all SolrClient methods without "collection" can be removed in favor of
insisting you use the overloaded variant accepting a collection, *or*
SolrClient itself could be locked down to one collection at the time you create
it *or* have a CollectionSolrClient interface retrieved from a
SolrClient.withCollection(collection) in which all the operations that require
a SolrClient are on that interface and not SolrClient proper. Several ideas to
consider.
Gus I'll move the logic out of SolrClient and commit later. I ran the tests
the other day via beasting + precommit and it passed.
> 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
