# Breaking Change: Change single operation shard hashing to only use id, and not id and type

**URL:** <https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507>\
**Category:** Elasticsearch\
**Created:** [November 3, 2010, 10:50am UTC](https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507 "2010-11-03T10:50:43Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [November 3, 2010, 10:50am UTC](https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507/1 "2010-11-03T10:50:43Z")

</div>

Hi,

```
Just pushed a breaking change (sorry!). Thought long and hard about this

```

one, and there is a flag to revert to the old behavior. Here are the  
details:

Currently, single operation hashing (index/delete/get) is using the type as  
part of the hashing to decide which shard to direct to. It make more sense  
to just use the id for several reasons.

First, the new routing control capability will allow to direct docs to be  
placed in the same placement of another doc (blog, and commends for example)  
just based on that doc id (the routing when indexing a comment can use the  
blog post id, and thats it).

There are future features where this type of hashing will really simplify  
them, so it make sense to make this change now.

This change will require to reindex the data. In order to revert back to  
using the type for hashing as well, set `cluster.routing.operation.use_type`  
to `true`. This means that a cluster can be started by setting this flag,  
start another cluster, and reindex data from the old cluster into the new  
cluster.

-shay.banon

---

<div class="post-metadata">

**Author:** ![jminard](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jminard/32/1848_2.png) [@jminard](https://discuss.elastic.co/u/jminard)\
**Post date:** [November 8, 2010, 4:14am UTC](https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507/2 "2010-11-08T04:14:45Z")

</div>

So, we can custom route using the routing control capability to do whatever  
we want...

## Does that allow things like shard selection for a given query? I.e. route a record to shards based on some sort of collection identifier, then on a query remove shards from the list for those that should not be included to resolve the query (i.e. don't query things that wouldn't contain any docs anyway to improve performance, or as another example don't query things that user doesn't have rights to by collection)

View this message in context: [http://elasticsearch-users.115913.n3.nabble.com/Breaking-Change-Change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type-tp1833986p1860842.html](http://elasticsearch-users.115913.n3.nabble.com/Breaking-Change-Change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type-tp1833986p1860842.html)  
Sent from the ElasticSearch Users mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\
**Post date:** [November 9, 2010, 9:12pm UTC](https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507/3 "2010-11-09T21:12:56Z")

</div>

Yes, you can pass a list of routing values when searching (comma separated).  
Only shards that match that routing will be searched on.

On Mon, Nov 8, 2010 at 6:14 AM, jminard [jayson.minard@gmail.com](mailto:jayson.minard@gmail.com) wrote:

> So, we can custom route using the routing control capability to do whatever  
> we want...
> 
> ## Does that allow things like shard selection for a given query? I.e. route a record to shards based on some sort of collection identifier, then on a query remove shards from the list for those that should not be included to resolve the query (i.e. don't query things that wouldn't contain any docs anyway to improve performance, or as another example don't query things that user doesn't have rights to by collection)
> 
> View this message in context:  
> [http://elasticsearch-users.115913.n3.nabble.com/Breaking-Change-Change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type-tp1833986p1860842.html](http://elasticsearch-users.115913.n3.nabble.com/Breaking-Change-Change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type-tp1833986p1860842.html)  
> Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com).

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 4:16am UTC](https://discuss.elastic.co/t/breaking-change-change-single-operation-shard-hashing-to-only-use-id-and-not-id-and-type/3507/4 "2017-07-06T04:16:52Z")

</div>


