Migrations are too aggressive on RenameColumn

[yepeekai]

We made huge refactoring of our model for a new application. There is a lot of RenameColumn in the generated Migration and a lot of them don't make sense: Foreign keys have been removed and added to different tables and EF Core choose to rename columns even when the foreign key is for a different table.

If we drop EntityAId (pointing to EntityA) and add EntityBId (pointing to EntityB), it shouldn't be a rename but a drop and add.

I think it should be a DropColumn and a AddColumn instead of a RenameColumn for a foreign key that points to different entities.

[ajcvickers]

@yepeekai It's not possible to know for sure when something is a rename, so sometimes the heuristics will detect dropping and adding as a rename when it isn't. We discussed this in triage and didn't come up with anything specific we can do better, but if you have any suggestions from your specific case we would be interested in hearing them.

[yepeekai]

I think the example I gave would qualify as a suggestion on a case that should not be a rename... If it is a foreign key and it is for a different table then it is not a rename...

[ajcvickers]

@yepeekai Thanks--we will discuss.

[schuettecarsten]

Maybe add an "OldColumnName" attribute to tell EFCore that a rename is useful when a migration is created...?

[304NotModified]

Maybe add an option to add-migration, e.g. -no-renames?

[jeff-pang]

Suggestion:
Add a new type of migration file "CustomMigration"

public partial class MyRenameCustomMigration : CustomMigration
{
    protected override void Up(CustomMigrationBuilder migrationBuilder)
    {
            migrationBuilder.RenameColumn(
                name: "FullName",
                schema: "sample",
                table: "Customers",
                newName: "FirstName");

            migrationBuilder.DoNotRename(
                name: "EntityAId",
                schema: "sample",
                table: "Customer");
}

migrations add RefactorCustomer --WithCustomMigration MyRenameCustomMigration

Ef migrations will generate other changes as usual but not touch the column names touched by the CustomMigration and then merge all changes into the migration file i.e RefactorCustomer

Future IDE tooling can also opt to include helpers to generate CustomMigration files with user input when performing class refactoring via IDE

[DanielPeinhopf]

I have another idea:
Why doesn't EF allow to add a DesignIdentity-attribute to entities and properties?
Eg.

[DesignIdentity("260d66ca-7e72-48cb-978d-c5d18f13bd67")]
public string? Name { get;set; }

This design identity could also be written to the column in the database by using extended properties on the column for example.
As long as the design identity stays the same, EF would know that it's still the same property and renaming it or changing it's type could result in the correct RENAME, ALTER COLUMN statements.

[jeff-pang]

I have another idea: Why doesn't EF allow to add a DesignIdentity-attribute to entities and properties? Eg.

[DesignIdentity("260d66ca-7e72-48cb-978d-c5d18f13bd67")]
public string? Name { get;set; }

This design identity could also be written to the column in the database by using extended properties on the column for example. As long as the design identity stays the same, EF would know that it's still the same property and renaming it or changing it's type could result in the correct RENAME, ALTER COLUMN statements.

DesignIdentity is a good solution in situation where the models is within the control of the developer and also the willingness to use annotate the models with [Attributes]. But this solution doesn't work very well in large project and teams where models are shared amongst teams and projects and tightly controlled. In this case annotating classes may or may not be in developer control also there may be large number of properties and classes to annotate.

[ajcvickers]

Consider also not renaming if multiple properties are equal candidates for the rename. See #29902.