IntentArchitect / Support

A repository dedicated to handling issues and support queries
3 stars 0 forks source link

Bug/feature: Aggregate roots + Shared DB Multi-tenancy #77

Closed shainegordon closed 10 months ago

shainegordon commented 10 months ago

What happened?

I don't know if this is a bug or a feature request.

If you have an owned entity, that entity won't be configured for multi-tenancy.

Steps to reproduce:

image

If you now run the software factory, you will see that only Parent gets builder.IsMultiTenant(); added to it's configuration. Running an initial dotnet ef migrations create will also show that only Parent gets a new TenantId field.

What version of Intent Architect are you using?

4.0.6

Additional information

I can understand why this happens: Child is owned by Parent, Parent has a TenantId, so through thet Child/Parent association, Child indirectly has a TenantId

I could see an issue arise, however, where you might want to change this relationship ownership to composition. This would require manual intervention. I also think that when browsing at the database level, it would be easier for a DBA to know which tables are multitenant vs which are not.

joelsteventurner commented 10 months ago

Hi @shainegordon This looks like a bug in our EF module, I've logged a ticket on our backlog to address this and will let you know when it's fixed.

joelsteventurner commented 10 months ago

As you mentioned the Finbuckle package doesn't support the 'IsMultiTenant()' on owned or composite entities.

You can model this by adding the Table Stereotype to the composite entity, which changes the EF Configuration to not be modelled as an Owned entity.

Let me know if this adequately addresses the issue, or you need further assistance around this.

I will be adding a feature into the 4.1. version of this module which will give you an error and recommend applying the Table Stereotype if people model this scenario in future.

shainegordon commented 10 months ago

Thanks for the feedback @joelsteventurner

We've settled on "Separate Databases" for our multitenancy strategy going forward, but the above will definitely be useful for others to know.