Add an advanced option to add .HasColumnName() to every single property during Reverse Engineering about efcorepowertools

[ErikEJ]

I am having some difficulties understanding the use case here.

Could you create a unit test to somehow help you?

[jscarle]

I often do migrations of legacy systems where I start developing new code on top of the same database that is being used by an older system.

If I scaffold such a database, I'll often end up with something that looks like this:

public class ProductConfiguration : IEntityTypeConfiguration<Product>
{
    public int ProductId { get; set; }
    public DateTime Created { get; set; }
    public DateTime Updated { get; set; }
    public string ProductName { get; set; } = "";
    public string Description { get; set; } = "";

    public void Configure(EntityTypeBuilder<Product> entity)
    {
        entity.HasKey(e => e.ProductId);

        entity.ToTable("Products");

        entity.Property(e => e.ProductId).HasColumnName("ProductID");
        entity.Property(e => e.ProductName).HasMaxLength(255);
    }
}

As you can see, there is no .HasColumnName() if there is no difference between the underlying database name and the property name. If I were to rename the property ProductName to simply Name in my entity, EF will then generate a migration to rename that column (which I do not want). Thus, the only way to prevent that is to go through ALL of my entity configurations and manually add a .HasColumnName() to every single one of my properties, which as you can imagine takes hours.

[ErikEJ]

So you are switching from reverse engineering to migrations ???

This is not very well supported, as scaffolding omits a lot of conventional model properties.

I will investigate.

[jscarle]

Yes, it's a very common scenario when migrating legacy systems. .HasColumnName() is a really good starting point because you can later on adjust your models for more specific properties such as precision as you develop against a test database, but at least you prevent the catastrophic breaking of column names which can make stored procedures completely explode.

[ErikEJ]

Iterate the DbContext model and persists a file with an ordered list (schema,table,column) - call it "baseline"

Add a test that compares the baseline with your current model to detect drift.

[jscarle]

That's an interesting approach. I'll take a look at how I could write that unit test efficiently. Though it still doesn't address my initial request. 🙃

[ErikEJ]

There is no simple way of doing that. It is not something I plan to implement

[jscarle]

I can appreciate that. Thanks anyway and keep up the great work!