Altering tables
Rename objects and evolve populated tables while preserving the schema details you still need.
Examples use Classic and Fluent tabs. Your choice follows you through the manual.
Rename a table and column
Use explicit old and new names. The column rename signature is table, old name, new name in both APIs. A table rename does not rename explicit constraints or their backing indexes. Reusing the original key name for a replacement table may collide on SQL Server or PostgreSQL.
Classic
Database.RenameTable("Users", "Members");
Database.RenameColumn("Members", "Name", "DisplayName");Fluent
migration.Rename.Table("Users").To("Members");
migration.Rename.Column("Name").OnTable("Members").To("DisplayName");Inside Up() / BuildUp(MigrationBuilder migration)
Change a complete column definition
Supply the type, length, nullability, default and collation you intend to retain. ChangeColumn replaces the column definition; it does not infer that table constraints should be created or removed. Existing rows must remain valid for the new definition.
Classic
Database.ChangeColumn("Users", new Column("Name", DbType.String, 500)
{
IsNullable = false
});Fluent
migration.Alter.Column("Name").OnTable("Users")
.AsString(500).NotNullable();Inside Up() / BuildUp(MigrationBuilder migration)
A deployment sequence for populated data
Add a nullable column, deploy code that can read both forms, backfill values, then enforce the final requirement in a later migration. Large data copies and index creation can hold locks for substantial time; test them against a representative dataset.
On SQLite, a supported alteration may recreate the table and copy rows. On Oracle and some other engines, DDL may commit implicitly. Review the transaction guide and your provider page before choosing the deployment boundary.