[
https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17166688#comment-17166688
]
Ishan Chattopadhyaya commented on SOLR-11868:
---------------------------------------------
{quote}[~dsmiley] I don't think I want to go there (remove <uniqueKey> and only
allow "id"). If we'd required that at the start it'd be one thing, but at this
point there are a lot of installations out there that use something different.
It just feels like too much difficulty for not enough gain.
{quote}
+1
> 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
> Fix For: 8.7
>
>
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
