Рельсы:Лучший способ внести изменения в производственную базу данных

Question

Мне нужно внести изменения в используемую производственную базу данных.Просто добавляю несколько столбцов.Я внес изменения в базу данных разработчиков с помощью миграции.Каков наилучший способ обновить производственную базу данных, сохранив существующие данные и не слишком сильно нарушая работу?

Это MYSQL, и мне нужно будет добавить данные в столбцы, а также для уже существующих записей.Один столбец может иметь значение по умолчанию (оно логическое), но другой является меткой времени и должен иметь произвольное значение, задним числом заданное.Количество строк невелико.

Итак, если я использую миграции, как мне добавить данные и как мне заставить их просто выполнять две (или три - я добавляю данные -последние миграции в рабочую базу данных, когда она изначально не была создана с помощью миграций (я полагаю, что вместо этого они использовали схему)?

Answer 1

Похоже, вы находитесь в состоянии, когда схема производственной базы данных не совсем соответствует тому, что вы используете в dev (хотя это не совсем ясно).Я бы провел линию на песке и привел этот prod db в лучшее состояние.По сути, то, что вы хотите сделать, это убедиться, что в базе данных prod есть таблица "schema_info", в которой перечислены любые миграции, которых у вас нет< вы когда-нибудь хотели работать в продакшене.Затем вы можете добавить миграции к своему содержимому hearts, и они будут работать с рабочей базой данных.

После того, как вы это сделаете, вы можете написать миграции, которые добавляют изменения схемы или добавляют данные, но одна вещь, с которой вам нужно быть действительно осторожным, заключается в том, что если вы добавляете данные с помощью миграции, вы должны определить модель в рамках самой миграции, вот так:

class AddSomeColumnsToUserTable < ActiveRecord::Migration
  class User < ActiveRecord::Base; end
  def self.up
    add_column :users, :super_cool, :boolean, :default => :false
    u = User.find_by_login('cameron')
    u.super_cool = true
    u.save
  end

  def self.down
    remove_column :users, :super_cool
  end
end

Причина этого в том, что в будущем вы можете полностью удалить модель во время какого-либо рефакторинга или чего-то другого.Если вы не определите класс user в строке "User.find_by_login ...", миграция выдаст исключение, которое является большой проблемой.

Answer 2

Я всегда следую этой процедуре:

• Дамп базы данных prod с помощью команды mysqldump
• Заполните базу данных разработки / тестирования дампом с помощью команды mysql
• Запуск миграции в dev / test
• Проверка того, что миграция сработала
• Дамп базы данных prod с помощью команды mysqldump (как это могло измениться) с сохранением резервной копии на сервере
• Запуск миграции на prod (с использованием capristano)
• Тестовая миграция сработала на prod
• Пейте пиво (просматривая журналы ошибок)

Answer 3

Есть ли причина, по которой вы не используете те же миграции, которые вы использовали в своей среде разработки?

Answer 4

Добавление столбца с add_column миграция должна быть неразрушающей:это сгенерирует инструкцию "ALTER TABLE".Если вы знаете, что вы собираетесь поместить в столбцы после создания, вы можете заполнить значения в процессе переноса (вы можете выбрать менее трудоемкий вариант, если количество строк велико).

Удаление или изменение определения столбца, я думаю, зависит от платформы:некоторые из них позволят удалить столбец на месте, другие выполнят последовательность команд переименовать-создать-выбрать-удалить.

Чтобы получить более подробную информацию, нам нужно больше информации:какого рода миграцию вы рассматриваете, на какой платформе вы работаете, нужно ли вам устанавливать значения как часть миграции?Подобные вещи очень помогли бы - просто отредактируйте вопрос, что вернет его обратно в список.