- ABP Framework version: v8.2.2
- UI Type: Angular
- Database System: PostgreSQL
- Tiered (for MVC) or Auth Server Separated (for Angular): separate Auth Server
- Exception message and full stack trace:
- Steps to reproduce the issue:
We created a solution with the separate schema for host and tenants option enabled with the goal to have a second database that will only contain the tenant-related data. Our hope was that we can specify a second connection string that would be used by default for new tenants. The option though seems to apply to the migration path only. Our first guess to edit the connection string attribute of the ...TenantDbContext did not result in the desired behavior and I think this isn't the intended way.
Manually specifying the desired connection string works
Is there an out-of-the-box feature to accomplish what we want to achieve? Did we miss something?
9 Answer(s)
-
0
hi
I do not fully understand your question.
What's the problem now? How to reproduce?
Can you explain more?
Thanks.
How To Add New Migration?
This solution configured so it uses two database schema;
- Default schema is used to store host & tenant data (when the tenant uses shared database).
- Tenant schema is used to store only the tenant data (when the tenant uses a dedicated database).
In this way, dedicated tenant databases do not have host-related empty tables.
To make this possible, there are two migrations
DbContextin theEntityFrameworkCoreproject. So, you need to specify theDbContextwhen you want to add new migration.When you add/change a multi-tenant entity (that implements IMultiTenant) in your project, you typically need to add two migrations: one for the default DbContext and the other one is for the tenant DbContext. If you are making change for a host-only entity, then you don't need to add-migration for the tenant DbContext (if you add, you will get an empty migration file).
Example: Adding Migration to the Default DbContext
Using Visual Studio Package Manager Console;
Add-Migration Your_Migration_Name -Context MyProjectNameDbContextUsing EF Core command line tool;
dotnet ef migrations add Your_Migration_Name --context MyProjectNameDbContextExample: Adding Migration to the Tenant DbContext
Using Visual Studio Package Manager Console:
Add-Migration Your_Migration_Name -Context MyProjectNameTenantDbContext -OutputDir TenantMigrationsUsing EF Core command line tool:
dotnet ef migrations add Your_Migration_Name --context MyProjectNameTenantDbContext --output-dir TenantMigrationsUpdating the Databases
It is suggested to run the
DbMigratorapplication to update the database after adding a new migration. It is simpler and also automatically handles tenant database upgrades. -
0
Thank you for your response. We understood the migrations part. It's more the overall concept as we expected b the description of the option that there would be a way to specify a default connection string for new tenants. We tried changing the connection string attribute of the MyProjectNameTenantDbContext but as we found out this only applies to the migrations, not to creating new tenants.
Is there an out-of-the-box way or are we supposed to explicitly set a connection string when creating new tenants that should not go into the host db?
-
0
hi
The tenant data have to be stored in the host db. This is the framework design.
-
0
Yes, the definitions of the tenants always go into the host db. But we can specify an alternate connection string for the tenant upon creation and that works as intended. But manually specifying a connection string via UI isn't what we expected from the feature.
-
0
hi
But we can specify an alternate connection string for the tenant upon creation and that works as intended
What do you mean by that? Can you describe it?
Thanks
-
0
If I use the shared database, the tenant is created in the shared (host) database specified by the default connection string from the app settings.
If I do not use the shared database (as in the screenshot in my previous post) then I specify a database connection string for the new tenant. Then entities for the tenant are stored via that connection string which may point to a different database.
With the option for separate schemas for host and tenant enabled, it is ensured the migrations only create the relevant tables depending on whether the db contains host and/or tenant via the two db contexts - as you also explained. This works fine.
We want all new tenants to be created in another database. But we do not want to manually specify the connection string each time. I know we could create the tenants programmatically and set the connection string. But before we do so I want to know if there is an intended way that we are missing or that is not well-documented on how to achieve this without additional code.
-
0
hi
I got your point.
You have to program to implement it, because the default
MultiTenantConnectionStringResolver/DefaultConnectionStringResolvercannot determine the current situation, it can only return the default connection string.https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.MultiTenancy/Volo/Abp/MultiTenancy/MultiTenantConnectionStringResolver.cs#L32
https://github.com/abpframework/abp/blob/dev/framework/src/Volo.Abp.Data/Volo/Abp/Data/DefaultConnectionStringResolver.cs#L29-L44
-
0
That's ok for us. I just wanted to make sure we are not missing anything fundamental.
-
0
: )
