Azure-cosmos-dotnet-v3: Stop requiring partition key parameter in the typed create, replace, upsert methods, infer from the data

[matthewhancock]

When porting over to the new SDK from DocumentDB I came across needing to specify a Partition Key on an action (create, upsert, etc.) with a CosmosResource. However, the Partition Key Path is also specified on creating a Container.

Shouldn’t the Partition Key automatically be handled by the Container instead of having to specify it on every Resource action? Or will there now be a Partition Key property on the Resource if it doesn’t have a property that follows the Path specified on the Container?

I’m using the Azure.Documents.Cosmos package (not Azure.Documents.Cosmos.Table).

Thanks!

[manigandham]

They mean different things:

When creating a container, you're specifying what field in the documents to use as the partition key for sharding the collection.

When manipulating the resources, you're specifying the actual value for the partition key (field) so that Cosmos DB knows which partition to route to.

[christopheranderson]

Sorry this change wasn't super clear. We'll use this issue to track this change. (I'll change the title)

v3 currently only works with partitioned containers. We're working on a backend feature that will make non-partitioned containers able to act like partitioned containers (but you can just pass null as the partition key if you want to not think about it). You can expect that be out in Jan/Early Feb. That release will also block creation of new non-partitioned containers via the v3 SDK (which is still currently possible in v3 today).

For now, you'll need to use v3 only with partitioned containers.

[matthewhancock]

They mean different things:

When creating a container, you're specifying what field in the documents to use as the partition key for sharding the collection.

When manipulating the resources, you're specifying the actual value for the partition key (field) so that Cosmos DB knows which partition to route to.

But a Resource modification is done within the context of a Collection, so couldn't the Partition Key Path be mapped to the respective property on the Resource automatically based on the Collection it was going to?

[kirillg]

For the typed programming model, we will stop requiring partition key value in the method signature/infer it from the body. For the stream, we would like to avoid parsing the stream.

[Elfocrash]

@kirillg Shouldn't this also be the case for the SQL execution path? I'm talking about CreateItemQuery and CreateItemQueryAsStream methods which also require the partition key. I thought the server would infer the partition key from the query anyway if the request is marked as a cross partition query (which currently is an internal property).

[mdrichardson]

v3 currently only works with partitioned containers. We're working on a backend feature that will make non-partitioned containers able to act like partitioned containers (but you can just pass null as the partition key if you want to not think about it).

@christopheranderson How's this change coming along? I'm porting over from DocumentDB for the Bot Framework team and am running into this issue on the C# side. Node side is working great, though!

Regarding OP's issue, more specifically, I'm also running into this. If I'm using await _container.Items.UpsertItemAsync..., should it not infer the correct partitionKey from the _container? Similarly, it makes it a little difficult to strongly type document upserts if the item needs to have { <myPartitionKeyName>: <myPartitionValue> } instead of something like { partitionValue: <myPartitionValue> } since partitionKey is already required in the upsertItemAsync method.

[kirankumarkolli]

yes partitonkey and id (for replace) can be inferred. Marking it for GA.

[kirankumarkolli]

Duplicate of #230