Support CosmosDB Repository Initialization When Container Does Not Exist

[LuisM000]

Currently, the ICosmosRepository (and its simplified versions like IAsyncRepository, IAsyncReadRepository, etc.) assumes that the CosmosDB container already exists. For example, in Program.cs, we usually configure the dependency injection like this:

builder.Services
    .AddCosmos(builder.Configuration)  
    .AddSingleton<IAsyncReadRepository<Employee>>(sp =>  
    {  
        return sp.GetRequiredService<ICosmosRepositoryFactory>().Create<Employee>("EmployeeContainer");  
    });  

The issue arises because classes like CosmosInitializer and CosmosRepositoryFactory assume the container is pre-created. For instance:

enmarcha/src/Encamina.Enmarcha.Data.Cosmos/CosmosInitializer.cs

Lines 54 to 65 in 2cfec68

	public Container GetContainer(string containerName)
	{
	return string.IsNullOrWhiteSpace(options.Database)
	? throw new MissingConfigurationException(ExceptionMessages.ResourceManager.GetFormattedStringByCurrentUICulture(nameof(ExceptionMessages.MissingDatabaseConfigurationParameterException)))
	: client.GetContainer(options.Database, containerName);
	}
	/// <inheritdoc/>
	public Container GetContainer(string database, string containerName)
	{
	return client.GetContainer(database, containerName);
	}

If we want to create the container (and potentially the database) dynamically, we need to use asynchronous methods, such as:

var container = (await cosmosClient  
    .GetDatabase(database)  
    .CreateContainerIfNotExistsAsync(containerName, "/my-partition-key", cancellationToken: cancellationToken))  
    .Container;  

This approach conflicts with Dependency Injection (DI) because DI is not designed to handle asynchronous operations.

Goal:
We need to revisit this setup and propose a solution that allows the use of CosmosDB repositories while dynamically initializing the container (and optionally the database) if it does not exist. This might involve rethinking the current repository factory or initialization process to make it compatible with asynchronous creation patterns.

Possible Issues to Address:
Configuration of the Container: When creating the container on the fly, we need to ensure that container-specific settings (like manualThroughput, partition key definition, indexing policies, etc.) are configured properly. These configurations may need to be passed dynamically or fetched from configuration files or environment variables.