[SERVER-37908] Improve the interface of `sh.shardCollection` Created: 02/Nov/18  Updated: 06/Dec/22  Resolved: 13/Feb/20

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.6.8, 4.0.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Danny Hatcher (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-37907 Sharding a collection with invalid op... Closed
Assigned Teams:
Sharding
Operating System: ALL
Steps To Reproduce:
  1. Launch a sharded cluster
  2.  sh.enableSharding("test") 

  3.  sh.shardCollection("test.foo", {_id:"hashed"}, {numInitialChunks:128}) 

  4. Error appears even though it should work
Participants:

 Description   

When sharding a collection with a hashed shard key, specifying documented options like numInitialChunks causes the operation to fail.

sh.shardCollection("test.foo", {_id:"hashed"}, {numInitialChunks:128})
{
	"ok" : 0,
	"errmsg" : "Hashed shard keys cannot be declared unique. It's possible to ensure uniqueness on the hashed field by declaring an additional (non-hashed) unique index on the field.",
	"code" : 72,
	"codeName" : "InvalidOptions",
	"operationTime" : Timestamp(1541185959, 4),
	"$clusterTime" : {
		"clusterTime" : Timestamp(1541185959, 4),
		"signature" : {
			"hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
			"keyId" : NumberLong(0)
		}
	}
}

This is because options parameter is being interpreted as the unique parameter despite the fact that the latter is optional.



 Comments   
Comment by Mira Carey [ 13/Feb/20 ]

This is a slight rough edge in the shell helpers, but is fairly easily discoverable by consulting the documentation. In interest of focusing on more urgent work, marking this wont fix

Comment by Kaloian Manassiev [ 27/Nov/18 ]

This ticket is essentially about improving the interface of the sh.shardCollection API. As it is defined now, it puts the key and the uniqueness as separate parameters and then accepts further options as a JSON document and this makes it somewhat error prone to use.

I am putting this on the Sharding Team's Backlog to be considered as we do the triage pass with alyson.cabral.

Comment by Danny Hatcher (Inactive) [ 05/Nov/18 ]

Because of that javascript limitation, most of the customer facing commands use a single document to contain everything that's optional. Is there a reason that we couldn't put unique : false as a field in that document? I think that would be expected behavior.

Comment by Kaloian Manassiev [ 05/Nov/18 ]

How is java script supposed to know which positional argument is numInitialChunks specified for? For this I think you need to explicitly call out the arguments:

sh.shardCollection("test.foo", key = {_id:"hashed"}, options = {numInitialChunks:128});

Comment by Danny Hatcher (Inactive) [ 05/Nov/18 ]

Good catch, linda.qin. So the bug here is that even though the unique parameter is supposed to be optional and default to false, it is not respected when specifying options. I'll rewrite the description and close SERVER-37907 as a dupe of this.

Comment by Linda Qin [ 05/Nov/18 ]

Note that the shardCollection command takes the following parameters:

sh.shardCollection(namespace, key, unique, options)

So

{numInitialChunks:128}

in the following command is treated as unique: true, hence the shardCollection reported that "Hashed shard keys cannot be declared unique".

sh.shardCollection("test.foo", {_id:"hashed"}, {numInitialChunks:128})

If we specified the unique parameter as false, then the command succeeded.

> sh.shardCollection("test.foo2", {_id:"hashed"}, false, {numInitialChunks:128})
{ "collectionsharded" : "test.foo2", "ok" : 1 }

Generated at Thu Feb 08 04:47:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.