gitlab-org--gitlab-foss/db/migrate/20161018024550_remove_prior...

# rubocop:disable Migration/RemoveColumn
class RemovePriorityFromLabels < ActiveRecord::Migration[4.2]
  include Gitlab::Database::MigrationHelpers

  DOWNTIME = true
  DOWNTIME_REASON = 'This migration removes an existing column'

  disable_ddl_transaction!

  def up
    remove_column :labels, :priority, :integer, index: true
  end

  def down
    add_column :labels, :priority, :integer
    add_concurrent_index :labels, :priority
  end
end
Add cop for use of remove_column remove_column should only be used in the up (or change) step of a migration if it's a post-deployment migration. Otherwise there will be downtime due to the ActiveRecord column cache, which we can avoid by using the IgnorableColumn concern in combination with a post-deployment migration. 2017-12-11 16:34:51 +00:00			`# rubocop:disable Migration/RemoveColumn`
Add version 4.2 to all existing migrations DB schema generated by a migration may look different in rails 4 and 5 (because rails 5 may use different default values). For this reason it's important to explicitly set for which rails version a migration was written for. See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912 2018-11-13 07:27:31 +00:00			`class RemovePriorityFromLabels < ActiveRecord::Migration[4.2]`
Split migration to create label priorities 2016-10-18 02:56:05 +00:00			`include Gitlab::Database::MigrationHelpers`

			`DOWNTIME = true`
			`DOWNTIME_REASON = 'This migration removes an existing column'`

			`disable_ddl_transaction!`

			`def up`
			`remove_column :labels, :priority, :integer, index: true`
			`end`

			`def down`
			`add_column :labels, :priority, :integer`
			`add_concurrent_index :labels, :priority`
			`end`
			`end`