Multi-database support

[IEvangelist]

Derived from #19:

Currently the library only supports a single database. To add multiple database support, we should first discuss all the implications, potential pitfalls, the best approach, the desired consumer patterns, and design an API that is simple.

Considerations:

• What impact does a change like this have on existing declarative attributes?
• How would this not break existing functionality?
• Could the IRepositoryFactory be used?
• Should the consumption pattern be based on compile-time, or runtime, i.e., does the consumer decorate an item, and that determines the database it belongs to, or are there overloads that the consumer can explicitly tell the call site "this belongs in this DB"?
• How would the configuration of an item or container change based on the database, or does it not need to?
• What changes need to be made to the RepositoryOptions.DatabaseId options?

[Rabosa616]

I would like to help.

I will download the code and check how could be implemented and give a proposal.

[mumby0168]

I like this idea, I think we could support this using the factory that you have mentioned, we could allow a tenant ID for example to pull a specific database.

I think the main decision we'd have to make is how this support would work. There are two options I think we can either supporting multiple databases under the same cosmos DB account (with the same connection string). Then we can just provide a discriminator to use containers from one database vs another.

The other option for more isolated multi-tenant applications would be multiple accounts support, which would be much harder. I also think this begs the question around the design of a multi tenant application. For example it might be better in that case to deploy a backend instance of the app per tenant. Then have some upstream service figure out which backed to call. There are many options to this second point. I feel it might be a little out of scope for the library.

Multiple databases under the same cosmos DB account however I think would be a nice addition.

I think the point in where we could branch to filter databases given a tenant key would be around here. We could almost have a ICosmosDatabaseProvider.

azure-cosmos-dotnet-repository/src/Microsoft.Azure.CosmosRepository/Services/DefaultCosmosContainerService.cs

Lines 48 to 50 in fe87219

	Database database =
	await _cosmosClientProvider.UseClientAsync(
	client => client.CreateDatabaseIfNotExistsAsync(_options.DatabaseId)).ConfigureAwait(false);

[hesperanca]

This would be great for us. At the moment we cannot use this library because of the lack of support for this feature.

Our use case is that we are an ISV and are building a multi tenant application. We need to be able to determine which database and container to use at runtime depending on the tenant that is connecting to the application. Tenants on our cheaper plans will be sharing a database but tenants on our more expensive plans may endup with a database just for them.

We also will have to be able to use multiple accounts because of the limit of 500 databases/containers per account.

Ideally we would like to have some sort of container factory where we pass in the name of the account, database and container and get the relevant container instance. I suspect that this factory would be a singleton that would hold a reference to a CosmosClient singleton per account.

[NielsFilter]

Hi @IEvangelist, I think your suggestion of allowing options to be passed along with the IRepositoryFactory is a good one IMO. By default the repository falls back to the options.DatabaseId setup in the Startup() and then give the opportunity to various services to update the options purely for that repository instance it's creating.

Also thanks for your time in creating this SDK for the community. It really makes implementing basic CRUD for cosmos super easy.

[todosrc]

any update on this ?