ClientTest->testDeleteIdsIdxStringTypeString fails about 1/3 of the time #633
Comments
nik9000
pushed a commit
to nik9000/Elastica
that referenced
this issue
Jun 13, 2014
ClientTest->testDeleteIdsIdxStringTypeString assumed that new documents created without a specified id or routing value would route to the same shard as "1" and a different shard from "2" when there are two shards. This wasn't always that case because: 1. Documents without a routing value use their ids as a route. 2. Documents that don't specify an id get a random one. This sets the routing for the document to "1" which, luckily, does in fact route to a different shard then "2" when there are two shards. And it will stay that way forever back Elasticsearch has to maintain a consistent routing style or it won't be safe to upgrade. Closes ruflin#633
nik9000
pushed a commit
to nik9000/Elastica
that referenced
this issue
Jun 13, 2014
ClientTest->testDeleteIdsIdxStringTypeString assumed that new documents created without a specified id or routing value would route to the same shard as "1" and a different shard from "2" when there are two shards. This wasn't always that case because: 1. Documents without a routing value use their ids as a route. 2. Documents that don't specify an id get a random one. This sets the routing for the document to "1" which, luckily, does in fact route to a different shard then "2" when there are two shards. And it will stay that way forever back Elasticsearch has to maintain a consistent routing style or it won't be safe to upgrade. Closes ruflin#633
nik9000
pushed a commit
to nik9000/Elastica
that referenced
this issue
Jun 13, 2014
ClientTest->testDeleteIdsIdxStringTypeString assumed that new documents created without a specified id or routing value would route to the same shard as "1" and a different shard from "2" when there are two shards. This wasn't always that case because: 1. Documents without a routing value use their ids as a route. 2. Documents that don't specify an id get a random one. This sets the routing for the document to "1" which, luckily, does in fact route to a different shard then "2" when there are two shards. And it will stay that way forever back Elasticsearch has to maintain a consistent routing style or it won't be safe to upgrade. Closes ruflin#633
nik9000
pushed a commit
to nik9000/Elastica
that referenced
this issue
Jun 13, 2014
ClientTest->testDeleteIdsIdxStringTypeString assumed that new documents created without a specified id or routing value would route to the same shard as "1" and a different shard from "2" when there are two shards. This wasn't always that case because: 1. Documents without a routing value use their ids as a route. 2. Documents that don't specify an id get a random one. This sets the routing for the document to "1" which, luckily, does in fact route to a different shard then "2" when there are two shards. And it will stay that way forever back Elasticsearch has to maintain a consistent routing style or it won't be safe to upgrade. ScanAndScrollTest->testQuerySizeOverride used the ->rewind method on ScanAndScroll which executes a scroll query on Elasticsearch without making sure that the index is fully allocated. Apparently, this can cause Elasticsearch to throw back an error. We work around this by adding a refresh before the rewind. Closes ruflin#633
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: