You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Erick Erickson (Jira)" <ji...@apache.org> on 2020/07/26 00:50:00 UTC
[jira] [Updated] (SOLR-11868) Deprecate CloudSolrClient.setIdField,
use information from Zookeeper
[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Erickson updated SOLR-11868:
----------------------------------
Summary: Deprecate CloudSolrClient.setIdField, use information from Zookeeper (was: CloudSolrClient.setIdField is confusing, it's really the routing field. Should be deprecated.)
> Deprecate CloudSolrClient.setIdField, use information from Zookeeper
> --------------------------------------------------------------------
>
> Key: SOLR-11868
> URL: https://issues.apache.org/jira/browse/SOLR-11868
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 7.2
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
>
> IIUC idField has nothing to do with the <uniqueKey> field. It's really
> the field used to route documents. Agreed, this is often the "id"
> field, but still....
> In fact, over in UpdateReqeust.getRoutes(), it's passed as the "id"
> field to router.getTargetSlice() and just works, even though
> getTargetSlice is clearly designed to route on a field other than the
> <uniqueKey> if we didn't just pass null as the "route" param.
> The confusing bit is that if I have a route field defined for my
> collection and want to use CloudSolrClient I have to figure out that I
> need to use the setIdField method to use that field for routing.
>
> We should deprecate setIdField and refactor how this is used (i.e. getRoutes). Need to beef up tests too I suspect.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org