Manual Tenant Switching Issue

[Rockstar1989]

Hi there;

I hope that you are doing well.

I have an enquiry with regards to switching a tenant at runtime, specifically, cycling through tenant IDs/identifiers to resolve their respective Database Contexts and carry out some sort of persistence.

We are currently making use of the host strategy for tenant resolution which of course works just fine, but we now have a use case where, given a list of tenant IDs, we want to persist some data to each tenant DB. This would be taking place in one of our API services - this can be thought of an "admin-level" task. Therefore, we would like to change the resolved tenant at runtime for each provided tenantId and use its resolved Database Context for persistence.

According to your documentation, the following line seems to provide what we are looking for, however, the Database Context after this call is not resolved.

_httpContextAccessor.HttpContext?.TrySetTenantInfo(tenantInfo, true);

Is the Database Context not being resolved for a newly set tenant expected behavior?

If so, what is value provided by the above line? What use case is the above satisfying/achieving?

If not, may I please ask for some assistance on what we may be doing incorrectly, and for any information that we have missed and should be aware of when tackling this problem/use case.

I look forward to hearing from you, thank you!

[AndrewTriesToCode]

Hi, there. It's somewhat of a manual process because in normal operation DI is used to get things going. I will post a solution for you in the next few days. Are you using Identity at all or just regular db contexts?

[Rockstar1989]

Thank you so much for getting back to me Andrew.

To answer your question, yes, currently my tenant database context are extending the IdentityDbContext.

Currently, my TenantDatabaseContext is just extending IdentityDbContext and then I make use of the injectable ITenantInfo so that I can access the connection string to be used OnConfiguring. I should however also be able to extend MultiTenantIdentityDbContext instead too, if need be - mentioning this just in case this is a required dependency for your solution you have in mind.