CosmosDB Repository Support

[richard-einfinity]

PR for CosmosDB repository support.

Add Cosmos Specific Repository with support for hierarchical partition keys.
Add Cosmos Specific Samples with bicep deployment files.
Add Cosmos Repository Test projects with additional Packed key specific tests.

[Copilot]

Copilot reviewed 30 out of 30 changed files in this pull request and generated 3 comments.

[adrianhall]

Aside from the two comments, there are also code style warnings being emitted - please fix those.

[adrianhall]

Is there significant overhead with creating a repository per request? Why not just create the repository within the table controller?

Ditto for the table options - why are they done here and not in the table controller?

[richard-einfinity]

I believe this is be correct use of DI. I like my config in one place not throughout the code, If I was going to swap out the implementation I'm doing it then in one place. I know this is complicated slightly by the provider specific ITableData implementation in this project. I've opted for Singleton registration in this case as there's no per request dependencies in the Repository or the Options, the CosmosClient is also singleton which is recommended.

Changing the registration to scoped would move these to be resolved per request.

[adrianhall]

Why is Newtonsoft required?

[richard-einfinity]

Hi Adrian, this is a dependency of the Cosmos Sdk even though I've elected to use System.Text.Json I believe Newtonsoft is still required under the hood.

[richard-einfinity]

I've attempted to remove the dependency and disable the check but the program crashes on the instantiation of the CosmosClient.

[adrianhall]

I’ll open a bug with the Cosmos folks on Monday. Newtonsoft should be defined as a transitive dependency in that case.

[richard-einfinity]

Hi @adrianhall, there are already multiple threads on this issue. We can mark the library to not required the dependency directly but then it would be up to the consumer to install it in their api project, it would generate an error at build time. We would still need it as a dependency then for the sample project. It's a bit of a mess, they seem to be one foot in one foot out.

[adrianhall]

After deploying the server (I copied and edited the azure.yml from the test service), I get the following when doing a request:

    <title> HTTP Error 500.30 - ASP.NET Core app failed to start </title>

What I did:

1. Change the long name in the .http file to @BaseURL to make it easier.
2. Copy the azure.yml from the existing sample to the new sample
3. Run "azd up" to deploy everything.
4. Open the solution
5. Run the request for creating an item.

Copying the CosmosDB connection string into the secrets.json ConnectionStrings:DefaultConnection results in a working system. Diagnosis - you aren't setting the ConnectionStrings__DefaultConnection to the right thing in the bicep code. This is the problem with working with App Service. the connection strings are not named what you expect them to be.

Suggest you do the following:

1. Add an azure.yml file and actually deploy the sample to Azure to ensure it is working.

2. Change the connectionString reader in Program.cs (line 17) of the sample to

   string connectionString = builder.Configuration.GetConnectionString("DefaultConnection")
       ?? builder.Configuration["DOCDBCONNSTR_DefaultConnection"]
       ?? throw new ApplicationException("DefaultConnection is not set");

There is a potential problem with the output of the library. Here is an example:

{"title":"Second item","isComplete":false,"id":"2","deleted":false,"updatedAt":"2025-02-21T21:21:05.056Z","version":"IjAwMDBjZGNjLTAwMDAtMDIwMC0wMDAwLTY3YjhlZTQxMDAwMCI=","_etag":"\u00220000cdcc-0000-0200-0000-67b8ee410000\u0022"}

While the version and ETag header match, the _etag doesn't match the version. Maybe it should? Why are you creating a version when the service provides one for you? The service doesn't provide an UpdatedAt property, but we should reuse the ETag rather than storing a version.

[richard-einfinity]

Hi @adrianhall

I'll take another look at the deployment as suggested. I had a little trouble with the azd tool, it's my first foray into bicep, I was expecting it to expand variables in the main.parameters.json file when passed, but it didn't. so ended up passing parameters on the command line. Ended up using az deploy to test. Perhaps the azure.yml file is the piece I was missing, I'll give it another go.

Version is the Base64Encoded value of the _etag. The base CosmosTableData is converting the _etag to bytes and the serializer is converting it to Base64.

Ideally, I don't want to be exposing the _etag and I don't really want Version saved in the store since it's derived from the cosmos generated etag... however as the model is using the same serializer attributes for both if I add an ignore attribute to the ETag its never retrieved from the store and if I ignore the Version properties it not serialized out via the api. I'm thinking it's one of those things we need to live with for now.

[richard-einfinity]

@adrianhall yaml file done the trick. Bicep file updated. azd up now works nicely.

[adrianhall]

Nice - and I agree with your sentiment on the _etag / version. It’s something we will live with.