Base solution for your next web application
Starts in:
01 DAYS
01 HRS
01 MIN
01 SEC
Open Closed

Multi-Tenant Implementation Question (IAbpZeroDbMigrator) #1316


User avatar
0
JeffMH created

I have a question. I am finally getting around to migrating over to the new release(which is awesome by the way!). I guess a quick recap of what I am doing:

I am splitting the context. I have a HostDbContext (inherits from AbpZeroHostDbContext) and an TenantDbContext (inherits from AbpZeroTenantDbContext). I am making the Host database strictly Hosts, if I am going to have a Shared database, it will not be in the Host DB. This makes Migrations much simpler IMO.

So, as I am making my changes, I come accross the AbpZeroDbMigrator. I notice this object that it inherits from will run migrations against both the Host and the Tenant databases but the class is only accepting one Context / Migration Configuration:

using Abp.Dependency;
using Abp.Domain.Uow;
using Abp.MultiTenancy;
using Abp.Zero.EntityFramework;

namespace MyPortal.Framework.EntityFramework
{
    public class AbpZeroDbMigrator : AbpZeroDbMigrator<TenantDbContext, Migrations_Tenant.Configuration>
    {

I changed this code to use just the TenantDbContext and the Tenant Migrations but this will only make the Create Tenant part of the system work. The Migrator console application needs to execute Migrator code for both the Host and the Tenant.

I am not sure what was intended for me to do here. Do I create a AbpTenantDbMigrator and AbpHostDbMigrator and modify the console application accordingly? I could implement another MultiTenantMigratorExecuter that would take in both Migrators....

Anyway, I am just looking for guidance. I sort of worked my way through what I thought you were intending me to do but there is not alot of guidance on using Multiple contexts, how to use the current migrations with both contexts, etc. I think you all need to come up with an example of using seperate DB's so we can see what you intended for us to do when using multiple contexts.

I will try and create a document on what I did. I would really like to know if I am doing everything "as intended". Once I get this part worked out, hopefully I can get that done.

Thanks!


3 Answer(s)
  • User Avatar
    0
    hikalkan created
    Support Team

    Hi,

    First of all, we used single DbContext for two reasons;

    1. To make migrations simpler (one database, one migration line)
    2. To allow tenants to store in host db. Thus, you can have a single database (this is especially good if you spend pay per database).

    But we also created two separated dbcontext for who want to separate them. And congratulations, you found them even we haven't document it :)

    See AbpZeroDbMigrator class:

    public class AbpZeroDbMigrator : AbpZeroDbMigrator<AbpZeroTemplateDbContext, Migrations.Configuration>
    
    1. It's clear that we need two dbmigrator in that case: one for host (AbpZeroHostDbMigrator) and one for tenants (AbpZeroTenantDbMigrator). Generic parameters allow us to set different dbcontext and migration configuration.

    2. You should change MultiTenantMigrateExecuter constructor to accept these 2 migrator instead of IAbpZeroDbMigrator interface.

    3. Use AbpZeroHostDbMigrator for host, AbpZeroTenantDbMigrator for tenant migration in MultiTenantMigrateExecuter .

    While I haven't tested it but only see when I checked the code, you can try that.

    As alternative, you can manage migrations yourself. Because, we created the Migrator.exe to make it simpler for startup template, but not replaced EF's own Migrate.exe or Package Manager Console commands. They are still there.

    Have a nice day.

  • User Avatar
    0
    JeffMH created

    Thanks for the quick reply.

    Yes, I tossed around keeping it one Context to simplify but I just liked the clean separation. I know it's a bit more complicated, but I just felt like I wanted the system to fail if I try and Add an Edition record to a Tenant DB. But I do respect keeping it one for simplification. I definitely did not want to use separate contexts with similar schemas.

    I will make these changes and share them here in case anyone else wants to be brave like me :)

    Before I start my next step, making all this work in Azure, have you all tried this yet? I am not 100% sure, but I have a feeling the Create tenant database process when adding a tenant won't work (not sure you can create DB's like that and not sure DTC works in Azure). Just wondering if you all may have worked through any of this.

    Thanks again!

  • User Avatar
    0
    hikalkan created
    Support Team

    Tenant creation probably will not work in Azure, yes. I'm not familiar with Azure, but probably they have a different API for that. But you can inject that logic into AspNet Zero. Before running migrations for tenant, create database via Azure API (I don't know if there is). I suppose you can easily find where to do it.