[SERVER-44865] updateZoneKeyRange command doesn't restrict hashed field values to NumberLong, if zone ranges are updated after sharding the collection Created: 27/Nov/19 Updated: 29/Oct/23 Resolved: 21/Apr/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Arun Banala | Assignee: | Gregory Noma |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Minor Change | ||||||||||||||||||||||||
| Backport Requested: |
v4.4
|
||||||||||||||||||||||||
| Sprint: | Sharding 2020-05-04 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
If zones ranges are created on a hashed shard key before sharding the collection, shardCollection command will fail if the zones range are not of type NumberLong. But updateZoneKeyRange command doesn't fail if zone ranges are updated after sharding the collection and the hashed field values are not NumberLong. This is bit inconsistent and error prone since users could potentially create zones ranges which cannot receive any data. This line in the test should fail when the shard key is hashed. |
| Comments |
| Comment by Githook User [ 21/Apr/20 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: |