Abp: what is the point of having separate dbcontext for migrations

[wocar]

If you need to create a new table you must add

    public DbSet<Entity> Entities { get; set; }

To both dbcontexts? The way I see it is that is more confusing, but there must be an advantage by using it, i just cant figure what is it.

Thank you

[wocar]

Also lets say I wanted to change, for example:
1.- The IdentityUser table from AbpUsers to "Usuarios" (Rename table)
2.- Change the column Email to "Correo" in IdentityUser (Rename column)

How can I do that with the lastest template? Thank you

Thank you!

[hikalkan]

Hi,

When we have a separated DbContext for each module, we need to a unified/merged dbcontext to maintain a single database schema. I think you understand that.

The question is "Why we don't have a single dbcontext in our application that merges module dbcontexts and adds our application entities?".

Simple answer is that it has some technical problems we had because of EF Core restrictions when you want to add new properties to existing entities or share a table between different entities. Tried that before, even forced it, but no way to make it possible.

Also, we believe it is technically wrong in point of modularity. You application dbcontext should have only entities of your own apps.

1.- The IdentityUser table from AbpUsers to "Usuarios" (Rename table)
2.- Change the column Email to "Correo" in IdentityUser (Rename column)

You can do these using EF Core fluent mapping API (here).

The latest design brings less compexity on object to relational maping while providing very flexible dbcontext & database structure.

[wocar]

Ok from an architectural point of view I get that each module needs its DbContext, I just didn’t consider the migrations project as a Module.

I tried using fluent mapping but the default unit tests in the template wouldn’t pass (AbpUsers table not found SqlException)

Could you be kind enough to give me an example on where exactly to use the fluent mappings? (IdentityUser entity? AppUser(Usuario) entity? In the migrations DbContext? Or in the App DbContext? Or in the CreatingModel shared extension method?)

Thank you for your fast response

[hikalkan]

OK, you want to rename a table and a column. Is that enough? If so, we'll write steps based on the latest template.

[wocar]

Yes please! IdentityUser/AppUser table rename to “Usuarios” for example... and Email column to “Correo”.

Very much appreciated!

[maliming]

@wocar I will try this and reply to you later.

[Webdiyer]

This can be done by changing xxxDbContextModelCreatingExtensions.cs file in the XXXEntityFrameworkCore project like below: @wocar

public static void ConfigureXXX(this ModelBuilder builder)
 {
builder.Entity<IdentityUser>(b =>
            {
                b.ToTable("AppUser");
                b.Property(nameof(IdentityUser.Email)).HasColumnName("Correo");
            });
}

I tested and it generated the correct migration file by using add-migration command, hope it helps!

[wocar]

In model creating extensions

public static void ConfigureXXX(ModelBuilder builder)
      builder.Entity<IdentityUser>(b =>
            {
                b.ToTable("Usuarios");
                b.Property(nameof(IdentityUser.Email)).HasColumnName("Correo");
                b.Property(nameof(IdentityUser.PhoneNumber)).HasColumnName("Telefono");
                b.Property(nameof(IdentityUser.Name)).HasColumnName("Nombres");
                b.Property(nameof(IdentityUser.Surname)).HasColumnName("Apellidos");
            });

Microsoft.Data.Sqlite.SqliteException : SQLite Error 1: 'no such table: AbpUsers'.

Then tried to fix it changing in my AppDbContext

            builder.Entity<Usuario>(b =>
            {
                b.ToTable("Usuarios"); //Sharing the same table "AbpUsers" with the IdentityUser
            });

And still throws

Microsoft.Data.Sqlite.SqliteException : SQLite Error 1: 'no such table: AbpUsers'.

However the migration file is generated correctly.

[hikalkan]

Changing it is impossible with the current design. It will correctly create migrations, but this only changes mapping for your app dbcontext & migrations db context. However, Identity module uses IdentityDbContext which uses builder.ConfigureIdentity(); and with the change suggested above, IdentityDbContext mapping is not effected. It is used on runtime & still looks for AbpUsers.

If you want to follow modularity best practices and name your table & fields as you want, you need to create your own users table and sync data between tables if you need.

We may work to allow to rename table & fields of DbContext of a module. However, it brings additional complexity and I think it has lower priority when we compare with all the waiting features.

I created https://github.com/abpframework/abp/issues/1327

If you want an advice, don't rename existing tables/fields :)