[Internal] Subpartitioning: Adds SDK changes to support subpartitioning.

[SrinikhilReddy]

SDK Changes to support Subpartitioning.

1. Adds the new PartitionKind 'MultiHash' which accepts multiple Partition keys.
2. Operations currently supported
   1. Document CRUD operations with MultiHash Partition Kind.
3. Changes done:
   1. New Class PartitionKeyBuilder.
   2. New ContainerProperties constructor that accepts an IReadOnlyList<string> object as multiple partition key paths
   3. Changes to extract multiple partition keys from the Resource object.

Sample usage of Collection create with MultiHash Partition kind and multiple partition key paths.

CosmosClient client = TestCommon.CreateCosmosClient(true);
Cosmos.Database database = await client.CreateDatabaseAsync("mydb");

ContainerProperties containerProperties = new ContainerProperties("mycoll", new List<string>{"/Zipcode","/City"});
Container container = await database.CreateContainerAsync(containerProperties);

Sample Document Create, where the PartitionKey is extracted from the resource stream.

Document  doc1 = new Document { Id = "Id1" };
doc1.SetValue("ZipCode", 15232);
doc1.SetValue("Address", "Pittsburgh");
await container.CreateItemAsync<Document>(doc1);

Reading back the document with the PartitionKey set during the read call.

PartitionKey partitionKey = new PartitionKeyBuilder()
                .Add(15232)
                .Add("Pittsburgh")
                .Build();                    
Document readDocument = (await container.ReadItemAsync<Document>("Id1", partitionKey )).Resource;

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

[j82w]

Object has a lot of negative feedback considering it only supports a very few primitive types. One option is to add a PartitionKeyValue type that has implicit conversion for the supported primitive types.

@kirankumarkolli, @FabianMeiswinkel, and @ealsur do you have any suggestions?

[FabianMeiswinkel]

To me consistency trumps everything else here - we used object for a single-value PK - so object[] is good enough for multiple.

I would also assume that this rarely results in issues with customers - at least I have ever heard of a customer trying to use a property that isn't string or numeric as the PK.

[ealsur]

The problem with object is the chance of runtime exceptions if the actual type is not supported.

[ealsur]

One idea (but it can cause inception issues) is to have PartitionKey(PartitionKey[] value). It can technically allow a PK that is an array to be passed as parameter to another PK constructor (array in array), but it's something the user would be actively doing. I think it boils down to reducing runtime exceptions, any check we add would generate runtime exceptions.

[j82w]

@FabianMeiswinkel we don't use object for single-value PK. We have explicit primitives on the PartitionKey constructor.

[SrinikhilReddy]

Hi guys, fixed as suggested.

[padmaaradhyula]

Thanks Jake for your suggestion. It looks good to me.

[j82w]

PartitionKeyBuilder pkBuilder = new PartitionKeyBuilder()
   .Add(15232)
   .Add("Pittsburgh");
                    
await container.ReadItemAsync<Document>("Id1", pkBuilder.Build())

List<PartitionKey> pKValueList = new List<PartitionKey>(){
  new PartitionKey(15232),
  new PartitionKey("Pittsburgh"),
};

Cosmos.PartitionKey pKey = new Cosmos.PartitionKey(pKValueList);
await container.ReadItemAsync<Document>("Id1", pKey)

[bchong95]

I thought we agreed not to provide the List overload?

[j82w]

Yes, we agreed to not provide the list overload. I posted that during the meeting to show the difference. I don't see a list overload in the code.

[ealsur]

The problem with object is the chance of runtime exceptions if the actual type is not supported.

[ealsur]

One idea (but it can cause inception issues) is to have PartitionKey(PartitionKey[] value). It can technically allow a PK that is an array to be passed as parameter to another PK constructor (array in array), but it's something the user would be actively doing. I think it boils down to reducing runtime exceptions, any check we add would generate runtime exceptions.

[j82w]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[SrinikhilReddy]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 1658 in repo Azure/azure-cosmos-dotnet-v3

[j82w]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[ghost]

Closing due to in-activity, pease feel free to re-open.