Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to CosmosClient creation #398

Closed
joelsteventurner opened this issue Jan 24, 2024 · 4 comments
Closed

Access to CosmosClient creation #398

joelsteventurner opened this issue Jan 24, 2024 · 4 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@joelsteventurner
Copy link
Contributor

I've been using this framework and am generally very happy with it, but I have run into a couple scenarios where the framework makes it difficult to do certain things. These issues all seem to stem from the fact that the CosmosClient instantiation is inaccessible.

The 2 scenarios that are proving problematic to me are as follows:

  1. Multi-tenancy, where I have a single application and each tenant has their own Cosmos instance

In this scenario I'd ideally want a cached CosmosClient per tenant, but the framework has a singleton CosmosClient and the factory interface for this ICosmosClientProvider is internal so I see no way to easily extend this.

  1. Automated Integration testing against a dockerized cosmos emulator

Here I am using Microsoft.AspNetCore.Mvc.Testing along with Testcontainers.CosmosDb to write automated integration tests. In this scenario I need to as part of the tests reconfigure my application, see example below. Here you can see the need for CosmosClient re-configuration / customization.

image

The feature I'd like to simply making the ICosmosClientProvider interface public so that custom implementations can be supplied.
Or more generally make it such that there is a factory which creates the CosmosClient, which can have its implementation swapped out.

This would allow me to create a MultiTenantCosmosClientProvider and an IntegrationCosmosClientProvider which I beleive would solve these issues.

@IEvangelist IEvangelist self-assigned this Jan 24, 2024
@IEvangelist IEvangelist added enhancement New feature or request help wanted Extra attention is needed labels Jan 24, 2024
@IEvangelist
Copy link
Owner

Hi @joelsteventurner - thank you for your kind words, and ideas here. I know that others have specifically asked for multitenancy support, that would be awesome to add! As for the idea around exposing the ICosmosClientProvider, I'm not opposed to that idea either. I recently helped with an addition to .NET Aspire to add emulator support, and I believe we should absolutely add that here too!

I love contributions, and I'm happy to work with you on making those a reality. What do you think?

@joelsteventurner
Copy link
Contributor Author

Hi @IEvangelist , that sounds great.

I'll submit a pull request for changing the interface accessibility from internal to public.

@joelsteventurner
Copy link
Contributor Author

@IEvangelist submitted the pull request.

@IEvangelist
Copy link
Owner

Closing this as #403 fixed it

joelsteventurner added a commit to joelsteventurner/azure-cosmos-dotnet-repository that referenced this issue Apr 10, 2024
…ch tenant connects to their own specific Cosmos DB

Along with the previous change I did to make ICosmosClientProvider public (IEvangelist#398)

* made ICosmosContainerProvider public
The Default implementation caches containers, I needed a custom implementation to cache these per Tenant
* Repository option
- I made DatanaseId, ContainerId and connection string virtual
Again in my implementation I need these to be tenant specific, making these virtual allows me over replace this with a MultiTenant version on RepositoryOptions
IEvangelist pushed a commit that referenced this issue Apr 10, 2024
…ch tenant connects to their own specific Cosmos DB (#428)

Along with the previous change I did to make ICosmosClientProvider public (#398)

* made ICosmosContainerProvider public
The Default implementation caches containers, I needed a custom implementation to cache these per Tenant
* Repository option
- I made DatanaseId, ContainerId and connection string virtual
Again in my implementation I need these to be tenant specific, making these virtual allows me over replace this with a MultiTenant version on RepositoryOptions
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants