discourse-migration

Dropping a column is a multi-step process: first mark it readonly with Migration::ColumnDropper.mark_readonly in a regular migration, add it to the model's ignored_columns, then drop it with Migration::ColumnDropper.execute_drop in a post-deploy migration. Remove the ignored_columns entry after the post-deploy migration is promoted.

db/migrate runs pre-deploy and is guarded by SafeMigrate, which blocks dropping or renaming tables and columns. db/post_migrate runs post-deploy with no safety restrictions, so all destructive operations belong there.

SafeMigrate blocks unsafe operations in db/migrate, such as dropping or renaming tables and columns, or creating concurrent indexes without first dropping existing ones. It is a dev/test guard only and is disabled in production.

No, application code must never be called in migrations because it breaks when code changes later. Query the database directly with execute or DB.query instead, for example reading site_settings rows by name.

Discourse mostly does not use foreign keys; referential integrity is enforced by application logic and the EnsureDbConsistency scheduled job. Foreign keys are only added selectively for critical relationships like uploads and security keys.

Use it only for operations that cannot run inside a transaction: concurrent index creation and batched data backfills. Keep such migrations limited to that single operation, since other schema changes would autocommit and leave the schema half-migrated on failure.