[SERVER-9371] addTagRange should prevent min and max being the same Created: 17/Apr/13 Updated: 11/Jul/16 Resolved: 04/Oct/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.2.4, 2.4.1 |
| Fix Version/s: | 2.5.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Asya Kamsky | Assignee: | Randolph Tan |
| Resolution: | Done | Votes: | 0 |
| Labels: | commands, sharding, tagging | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
Currently there are extensive checks to make sure that tag ranges don't overlap but it's allowable to set tagrange to have the same min and max. In the code this seems to result in matching nothing. This means that people who try to create a tag range to cover a single value of the shard key cannot do it via {min: VALUE, max: VALUE}as that will match nothing. If it's supposed to match VALUE then code needs to be changed, if the range should be { min: VALUE, max: <VALUE+1> }(logical next possible value) then the sh.addTagRange() function should reject min==max and maybe docs should call out this case. (in compound shard keys this is easy because you then use VALUE,$minKey to VALUE,$maxKey, this seems to be the problem with simple shard keys). |
| Comments |
| Comment by auto [ 04/Oct/13 ] |
|
Author: {u'username': u'renctan', u'name': u'Randolph Tan', u'email': u'randolph@10gen.com'}Message: |
| Comment by Randolph Tan [ 22/Apr/13 ] |
|
Oh, stupid me. You're right. I'll incorporate the check in the new command. |
| Comment by Asya Kamsky [ 22/Apr/13 ] |
|
Fixed how? min==max ends up being no keys matched (since top of range is exclusive). On the other hand, you can't have a chunk that has range min==max so why would it be different for tag ranges? |
| Comment by Randolph Tan [ 22/Apr/13 ] |
|
asya Come to think of it, I don't see why min == max should be disallowed. I think the code performing the matching should be fixed instead. |
| Comment by Randolph Tan [ 17/Apr/13 ] |
|
asya I'm working on converting these into actual server commands ( |