Can TenantId be set automatically when part of the PK using .IsMultiTenant().AdjustKey() ?

[dirraj]

Imagine I am creating a new Blog in my database using Finbuckle and Per-Tenant EF Core.

I find that if the new Blog has a PK of Id+TenantId, having used .IsMultiTenant().AdjustKey() in my model, I am forced to provide Blog.TenantId manually rather than relying on SaveChanges().

If I do not add TenantId to my model an exception is thrown:

Unable to track an entity of type Blog because its primary key property 'TenantId' is null

The Tenant context is working correctly. Version is 6.9.0.

Does AdjustKey() always require a TenantId and explicit set, or is there a pattern which avoids this?

Also, when a shadow TenantId is added as a FK on the related BlogPosts entity, does this TenantId participate in QueryFiltering standalone? In other words, would BlogPosts in another tenant be found if the BlogPosts entity is not marked as MultiTenant? The docs are unclear on this and only explained that, "a FK may be added as a result of the PK".

Thank you.

[AndrewTriesToCode]

Hi, sorry I didn't see this sooner. There is a property on MultiTenantDbContext called TenantNotSetMode which you should be able to set to Overwrite and it should set the tenant for you. Docs here.

Regarding a related entity like Posts, the filtering doesn't apply there unfortunately -- this is a limitation of global query filters which this Finbuckle functionality it based on.

[dirraj]

Thanks so much Andrew. I hadn't appreciated this use case for Overwrite until I got more familiar with the framework.

I found that where I have an explicit TenantId property used in a compound PK I need to have a non-null default value set as an initial value, then rely on TenantNotSetMode.Overwrite to correct it on SaveChanges, as you say.

In my case explicit TenantId is initially set to Guid.Empty.ToString(), EF attaching does not complain, and Finbuckle later corrects the TenantId on SaveChanges.

Having seen your comments elsewhere however, I'm leaning towards dropping the compound key (by removing AdjustKey) on the basis I am using a GUID PK anyway. Possibly suffering a very slight loss of query performance based on independent indexes.

But it's good to have both options, thank you.

[fretje]

Hmm. I can't seem to get this to work with TenantNotSetMode as TenantNotSetMode only comes into play when TenantId is null, but you can't add an entity with a null primary key to ef core's changetracker...

So it does work if I set TenantId to an empty string, but then I have to use TenantMismatchMode in stead... but I would rather not do that. I'd like to get an exception if a TenantId actually is mismatched... just not when it's emtpy.

[AndrewTriesToCode]

@fretje I see what you mean. In what use case would you want to have a record with a null (or empty if a workaround) tenant? I usually recommend that people have a "default" tenant to use in cases where no specific tenant is needed -- helps avoid issues like this with null and also with DI when a tenant is needed but DI throws exceptions if no tenant was found.

[fretje]

Hi @AndrewTriesToCode.
Maybe I wasn't making myself clear... I don't want a record with a null (or empty) tenantId value... I want Finbuckle to take care of (i.e. set) the tenantId, just like it does with all the other tenantId's in the database... It's just that in this case, the tenantId is part of the primary key, which means I can't use DbContext.Set<T>.Add(entity) with an entity that has that tenantId set to null. You get an EF Core exception when you try to do that. I can add it when the tenantId is emtpy though... but then it doesn't get picked up by Finbuckle when I use TenantNotSetMode, only with TenantMismatchMode...

I guess my question is: could the test you do with TenantNotSetMode use string.IsNullOrEmpty(tenantId) in stead of tenantId is null? ;-)

[AndrewTriesToCode]

hi @fretje

That would be a breaking change, maybe another value for that like TenantNotSetMode.OverwriteIfNullOrEmpty? Would you mind creating a new issue for this?

[AndrewTriesToCode]

Excellent. I'm glad it worked out for you and thank you for the sponsorship.