[ https://issues.apache.org/jira/browse/SOLR-11868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663225#comment-16663225 ]
Erick Erickson commented on SOLR-11868: --------------------------------------- Actually, I've long thought that allowing the <uniqueKey> to be something besides "id" is more trouble than it's worth, so AFAIC, standardizing would be fine. > CloudSolrClient.setIdField is confusing, it's really the routing field. > Should be deprecated. > --------------------------------------------------------------------------------------------- > > Key: SOLR-11868 > URL: https://issues.apache.org/jira/browse/SOLR-11868 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org