You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Erick Erickson (JIRA)" <ji...@apache.org> on 2018/01/17 22:48:01 UTC

[jira] [Created] (SOLR-11868) CloudSolrClient.setIdField is confusing, it's really the routing field. Should be deprecated.

Erick Erickson created SOLR-11868:
-------------------------------------

             Summary: 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


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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org