Dropping a table is destructive and should be the final step of a compatibility sequence, not the first release that stops using the table.
Before writing the migration:
- Search the repository for the table, entity, columns, relations, and queries.
- Identify every foreign key that references the table and every table it references.
- Decide whether dependent tables must be migrated first or whether their relationship should be removed in an earlier migration.
- Check whether indexes, enum types, seed rows, or application configuration also need cleanup.
Remove the entity/module only after the migration and callers have been coordinated. The migration should explicitly drop dependent constraints or tables in the required order. Avoid CASCADE unless all affected objects and data have been reviewed.
Example:
async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr>
{
manager
.drop_table(Table::drop().table(Widgets::Table).to_owned())
.await
}
Do not use if_exists to hide an unexpected schema state unless that behavior is intentional and documented. A missing table may indicate that an earlier migration did not run correctly.
If the table contains user data, down generally cannot restore it. Make down an explicit no-op and explain the data-loss limitation, or preserve and restore the data through a carefully designed reversible migration.