Open Closed

Understanding Options for Separate Tenant Schema #7857


User avatar
0
nitrovent created
  • 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)
  • User Avatar
    0
    maliming created
    Support Team Fullstack Developer

    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 DbContext in the EntityFrameworkCore project. So, you need to specify the DbContext when 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 MyProjectNameDbContext
    

    Using EF Core command line tool;

    dotnet ef migrations add Your_Migration_Name --context MyProjectNameDbContext
    

    Example: Adding Migration to the Tenant DbContext

    Using Visual Studio Package Manager Console:

    Add-Migration Your_Migration_Name -Context MyProjectNameTenantDbContext -OutputDir TenantMigrations
    

    Using EF Core command line tool:

    dotnet ef migrations add Your_Migration_Name --context MyProjectNameTenantDbContext --output-dir TenantMigrations
    

    Updating the Databases

    It is suggested to run the DbMigrator application to update the database after adding a new migration. It is simpler and also automatically handles tenant database upgrades.

  • User Avatar
    0
    nitrovent created

    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?

  • User Avatar
    0
    maliming created
    Support Team Fullstack Developer

    hi

    The tenant data have to be stored in the host db. This is the framework design.

  • User Avatar
    0
    nitrovent created

    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.

  • User Avatar
    0
    maliming created
    Support Team Fullstack Developer

    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

  • User Avatar
    0
    nitrovent created

    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.

  • User Avatar
    0
    maliming created
    Support Team Fullstack Developer

    hi

    I got your point.

    You have to program to implement it, because the default MultiTenantConnectionStringResolver/DefaultConnectionStringResolver cannot 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

  • User Avatar
    0
    nitrovent created

    That's ok for us. I just wanted to make sure we are not missing anything fundamental.

  • User Avatar
    0
    maliming created
    Support Team Fullstack Developer

    : )

Made with ❤️ on ABP v9.0.0-preview. Updated on October 07, 2024, 08:52