Pomelo.entityframeworkcore.mysql: Renaming Entity

This is an inherent limitation of EF, not Pomelo directly. EF cannot normally distinguish between a table drop/create, and a rename.

The trick to tell it that it's a rename is to set the table name manually, either via an attribute on the entity class, or via the OnModelCreating fluent API.

The sequence goes like:

1. Using the original entity name, set the table name to the new value. Try to make sure this new name is correct for the new entity, or you may end up with an additional migration.

E.g builder.Entity<OriginalEntity>().ToTable("RenamedEntity");

1. Generate a migration. This will create the correct rename table migration for the entity.
   Verify this migration is correct. If you are using Pomelo 2.2.6, check for migrationBuilder.DropPrimaryKey and AddPrimaryKey entries and delete them, since these are not necessary for MySQL and will cause issues with generating idempotent SQL scripts. This is fixed in 3.1.

2. Rename the actual entity class.

3. Generate another migration to update the model snapshot with the new entity names.

If you then want to remove the .ToTable("RenamedEntity"); to fall back to convention based table naming:

1. Remove the .ToTable("RenamedEntity");. If you got the table name correct, the convention based name should be the same as the current name.

2. Generate a final migration to verify that the table isn't renamed again. If it was, revert all steps, correct the name, and redo. If the migration was empty, you can revert it.

I'm yet to test it out, but you can probably do this in the reverse order to. I.E:

1. Rename the entity, and add the .ToTable with the current table name
2. Generate a migration.
3. Remove the .ToTable attribute
4. Generate another migration.

For more information, see this stack overflow question:

https://stackoverflow.com/questions/13296996/entity-framework-migrations-renaming-tables-and-columns

Basically, there are heuristics implemented, that can detect a table rename in _some_ cases.

But renaming is one of those operations, where you definitely want to check the generated migration code afterwards and change the DropTable and CreateTable calls to RenameTable where necessary.

EF Core has rename table just like these auto generated migration.

        migrationBuilder.DropPrimaryKey(
            name: "PK_LogFieldsConfiguration",
            table: "LogFieldsConfiguration");

        migrationBuilder.RenameTable(
            name: "LogFieldsConfiguration",
            newName: "LogFieldsConfigurations");

        migrationBuilder.AddPrimaryKey(
            name: "PK_LogFieldsConfigurations",
            table: "LogFieldsConfigurations",
            column: "Id");