discourse/db/migrate/20180917034056_remove_superfluous_tables.rb

# frozen_string_literal: true

require "migration/table_dropper"

class RemoveSuperfluousTables < ActiveRecord::Migration[5.2]
  DROPPED_TABLES = %i[category_featured_users versions topic_status_updates]

  def up
    DROPPED_TABLES.each { |table| Migration::TableDropper.execute_drop(table) }
  end

  def down
    raise ActiveRecord::IrreversibleMigration
  end
end
DEV: enable frozen string literal on all files This reduces chances of errors where consumers of strings mutate inputs and reduces memory usage of the app. Test suite passes now, but there may be some stuff left, so we will run a few sites on a branch prior to merging 2019-05-03 08:17:27 +10:00			`# frozen_string_literal: true`

DEV: Apply syntax_tree formatting to `db/*` 2023-01-09 11:59:41 +00:00			`require "migration/table_dropper"`
FEATURE: Post deployment migrations. (#6406) 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`. 2018-10-08 15:47:38 +08:00
			`class RemoveSuperfluousTables < ActiveRecord::Migration[5.2]`
DEV: Remove logical OR assignment of constants (#29201) Constants should always be only assigned once. The logical OR assignment of a constant is a relic of the past before we used zeitwerk for autoloading and had bugs where a file could be loaded twice resulting in constant redefinition warnings. 2024-10-16 10:09:07 +08:00			`DROPPED_TABLES = %i[category_featured_users versions topic_status_updates]`
FIX: Create readonly functions during backup Temporarily recreate already dropped functions in the discourse_functions schema in order to allow restoring of backups which still reference dropped functions. 2019-08-08 16:06:27 +02:00
			`def up`
DEV: Apply syntax_tree formatting to `db/*` 2023-01-09 11:59:41 +00:00			`DROPPED_TABLES.each { \|table\| Migration::TableDropper.execute_drop(table) }`
FEATURE: Post deployment migrations. (#6406) 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`. 2018-10-08 15:47:38 +08:00			`end`

			`def down`
			`raise ActiveRecord::IrreversibleMigration`
			`end`
			`end`