[ 
https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13704718#comment-13704718
 ] 

Jack Krupansky commented on SOLR-5017:
--------------------------------------

bq.  ImplicitDocRouter 

I started referring to this as "manual routing", meaning that Solr cannot 
automatically figure out which shard a document is in unless the user 
manually/explicitly specifies the shard.

Overall, I would say that we have this menu of routing techniques:

1. Manual URL, specifying the shard URL or directing the request to the shard 
URL.
2. Manual shard ID, specifying the shard ID/name as a parameter. SolrJ or the 
receiving node can look up the shard URL in clusterstate.
3. Fully automatic, hashing the full, raw ID key value.
4. Directed automatic or key-directed automatic, hashing the "!" prefix of the 
composite key value. (I called this "explicit routing" at one point.)
5. Field-directed automatic, the proposal for using a non-ID field's value for 
the surrogate key to hash.

As far as the atomic update issue for field-directed routing, there are three 
choices:

1. Update request includes the specified alternative (non-ID) routing field.
2. If not present, a "shard" parameter would be required, specifying either the 
shard ID or the surrogate key value to be hashed.
3. If neither is present, an error.

That still leaves the update issue of changing the field-directed key value. 
This is not just an atomic update issue - replacing the full document also has 
this problem, when the specified routing field value changes, which may mean 
that the updated document now belongs in another shard.



                
> Allow sharding based on the value of a field
> --------------------------------------------
>
>                 Key: SOLR-5017
>                 URL: https://issues.apache.org/jira/browse/SOLR-5017
>             Project: Solr
>          Issue Type: Sub-task
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>
> We should be able to create a collection where sharding is done based on the 
> value of a given field
> collections can be created with shardField=fieldName, which will be persisted 
> in DocCollection in ZK
> implicit DocRouter would look at this field instead of _shard_ field
> CompositeIdDocRouter can also use this field instead of looking at the id 
> field. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to