Is it possible to configure unique key policy for cosmos container in apphost?

[primozstu]

I am trying to configure a unique key policy for my Cosmos DB container in AppHost but can't figure out how to do it. I tried configuring the provisioned infrastructure of the Cosmos DB resource, but I didn't find an option to configure containers. Additionally, the AddContainer API does not seem to allow passing custom configurations when defining a container.

Am I missing something, or is this not supported at the moment?

It would be great if the API allowed something like this:

.AddContainer("YourContainerName", "/partitionKeyPath", containerOptions =>
{
    containerOptions.UniqueKeyPolicy = new UniqueKeyPolicy
    {
        UniqueKeys =
        {
            new UniqueKey { Paths = { "/propertyA", "/propertyB" } }
        }
    };
});

[msivers]

This is really needed, otherwise you can't setup a container properly in the AppHost (unless I'm missing something). For most real-world/production scenarios you will need to define unique keys (which has to be done at creation time) as well as other configuration for the container. It's odd that this isn't possible from the get go as it's pretty fundamental to setting up a container?!

I keep running into constraints like this when trying to build my solution using .NET Aspire... @davidfowl you mentioned on another comment I made on a similarly issue #667 that you are not prioritising integration... does that mean the .NET Aspire Cosmos DB integration will not get any attention?... in which case how viable is .NET Aspire going to be going forward if we keep hitting dead ends? .NET Aspire is promoted as being for production-ready apps but in this case not if you want to use Cosmos?

Hopefully you can correct me if I am missing something @davidfowl / @maddymontaquila / @eerhardt ?

[msivers]

Thanks for the prompt response @davidfowl I appreciate it.

For reference, I'm embarking on building a new platform from scratch and get it into production in a very tight timescale, and based on all the many Microsoft presentations and hype for .NET Aspire I was sold on the ease and apparent wealth of integrations such as Cosmos DB. It's just a bit frustrating when you see over simple video walkthroughs and documentation (e.g. https://learn.microsoft.com/en-us/dotnet/aspire/database/azure-cosmos-db-integration) where it all sounds a breeze but you end up hitting something of a dead end and then have to back track and skip the Aspire provision and do it manually... it just saps time that is already in short supply.

Anyways - having said all that, I take on board all that you have said and hopeful there will be plenty of benefit to using Aspire - I guess it's relatively early days. I'm sure I'll be glad I persevered in the future... in the meantime I will err on leading with more manual (non-aspire) implementation and then look to refactor to first class implementation at a later date when I have more time (and potentially can contribute).

Thanks again.

[davidfowl]

There shouldn’t be a dead end, if there is, we want to know otherwise it might be documentation gap.

PS: If you want a mental model for how to think about this, cosmos db (or any integration) is like an asp.net core middleware, each middleware has a set of features that you can use, is extensible and you can build your own as well. Dont throw away asp.net core because it might be missing a middleware or a feature of a middleware. Spend the time learning how to extend the system (I guarantee you it will be easier than full manual mode).

[msivers]

I think we're losing sight of the original issue, which is my fault for making wider comments regarding .NET Aspire - so apologies for that.

If we just focus on the issue with .NET Aspire + Cosmos DB integration ... when you follow the documentation https://learn.microsoft.com/en-us/dotnet/aspire/database/azure-cosmos-db-integration and you do this...

var builder = DistributedApplication.CreateBuilder(args);

var cosmos = builder.AddAzureCosmosDB("cosmos-db");
var db = cosmos.AddCosmosDatabase("db");
var container = db.AddContainer("entries", "/id");

// After adding all resources, run the app...

... it's so simple and is the beauty of using Aspire! Great!... but as soon as you want to do pretty basic and almost essential configuration of your container - such as setting up unique keys - then you can't use the documented code for creating your container and have to go down a different route which negates what the integration is there for. If we can simply pass the containerOptions parameter as the original poster has suggested, then we are in a really great place and you have good parity with the underlying AzureCosmosDBContainerResource capability.

Same goes for having ability to pass CosmosClientOptions to AddAzureCosmosDB.

Just seems to be required capabilities to facilitate real-world production scenarios.

[davidfowl]

If we can simply pass the containerOptions parameter as the original poster has suggested, then we are in a really great place and you have good parity with the underlying AzureCosmosDBContainerResource capability.

Sounds good to me, make it a real API propsoal and send a pull request (or someone with cosmos expertise will send it).

Same goes for having ability to pass CosmosClientOptions to AddAzureCosmosDB.

Frankly, this should just be part of the cosmos sdk and not part of aspire.

[davidfowl]

Actually, we already have a issue for this one #9143