[SERVER-2326] "unique: true" in shardcollection command does not check that the index used has been created as unique Created: 04/Jan/11 Updated: 12/Jul/16 Resolved: 30/Mar/11 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 1.9.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Antoine Girbal | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
The uniqueness of the key used as shard key is enforced by: I'm wondering what the "unique: true" actually does when calling > db.runCommand( { shardcollection : "mydb.fs.files", key : { filename: 1 }, unique: true }) ) , unique: true }) { "collectionsharded" : "mydb.fs.files", "ok" : 1 }> use mydb , , this turns out to be a bug: the shardcollection command should fail if it was called with "unique: true" but the existing index used is not unique. |
| Comments |
| Comment by auto [ 30/Aug/11 ] |
|
Author: {u'login': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@10gen.com'}Message: Add more tests for |
| Comment by auto [ 30/Mar/11 ] |
|
Author: {u'login': u'gregstuder', u'name': u'gregs', u'email': u'greg@10gen.com'}Message: fix for |
| Comment by Lexi Pimenidis [ 13/Jan/11 ] |
|
BTW, I'm just about to enable sharding on a 230GB-database, actually trying to use the unique-option. |
| Comment by Eliot Horowitz (Inactive) [ 04/Jan/11 ] |
|
Most times people enablesharding its empty, so that's definitely correct. |
| Comment by Antoine Girbal [ 04/Jan/11 ] |
|
Right now, the only case where "unique: true" works is when it is called on an empty collection, in which case the index gets created automatically. |