i take it MyDbContext : EFCoreStoreDbContext<TenantInfo>, IMultiTenantDbContext is a mistake?

[vigouredelaruse]

hello; congrats again for filling a multitenancy gap in the entire .net stack

with our first year compsci hats on, given it's been a while for me, is it supported for custom stores to participate in ef core tenant isolation?

seems the obvious risk is the store triggers tenant resolution which looks in the store which triggers tenant resolution infinitely but it would be good if the scenario could be definitevely shot down

please advise

[AndrewTriesToCode]

Hi, usually the tenant store itself is not "multitenant" although in some rare situations that might be feasible. Rather than an infinite loop what would usually happen is that the store raises an exception because it was unable to inject the the ITenantInfo.

If this is something you want to try I recommend separating out the tenant resolution for the store itself. you can instantiate TenantResolver and loop through its IMultiTenantStrategies to find a likely identifier then use to instantiate the store to be used in the ASP.NET Middleware. This logic would need to be in the store constructor or a factory method used for injecting the store.

[vigouredelaruse]

thanks for the reply/consult. i'm asking because i store all tenants in the idistributedcache but i want to prevent cache entry expired tenant resoluton 'gaps'. thus the dbcontext that feeds the cache reload can simply be another store, there to back the cache

based on what you've said i think i can proceed with the scenario which is

IMultiTenantStore -> MyDbQueryService -> MyDbContext : IMultiTenantDbContext.

for now i do not enforce multitenant on savechanges in the MyDbContext in question.

thanks again