mirror of
https://github.com/discourse/discourse.git
synced 2024-11-23 02:19:27 +08:00
40fa96777d
This moves us away from the delayed drops pattern which was problematic on two counts. First, it uses a hardcoded "delay for" duration which may be too short for certain deployment strategies. Second, delayed drop doesn't ensure that it only runs after the latest application code has been deployed. If the migration runs and the application code fails to deploy, running the migration after "delay for" has been met will cause the application to blow up. The new strategy allows post deployment migrations to be skipped if the env `SKIP_POST_DEPLOYMENT_MIGRATIONS` is provided. ``` SKIP_POST_DEPLOYMENT_MIGRATIONS=1 rake db:migrate -> deploy app servers SKIP_POST_DEPLOYMENT_MIGRATIONS=0 rake db:migrate ``` To aid with the generation of a post deployment migration, a generator has been added. Simply run `rails generate post_migration`.
22 lines
594 B
Ruby
22 lines
594 B
Ruby
require_dependency 'migration/base_dropper'
|
|
|
|
module Migration
|
|
class Migration::TableDropper
|
|
def self.read_only_table(table_name)
|
|
BaseDropper.create_readonly_function(table_name)
|
|
|
|
DB.exec <<~SQL
|
|
CREATE TRIGGER #{BaseDropper.readonly_trigger_name(table_name)}
|
|
BEFORE INSERT OR UPDATE OR DELETE OR TRUNCATE
|
|
ON #{table_name}
|
|
FOR EACH STATEMENT
|
|
EXECUTE PROCEDURE #{BaseDropper.readonly_function_name(table_name)};
|
|
SQL
|
|
end
|
|
|
|
def self.execute_drop(table_name)
|
|
DB.exec("DROP TABLE IF EXISTS #{table_name}")
|
|
end
|
|
end
|
|
end
|