Rails: лучший способ внести изменения в производственную базу данных - PullRequest
10 голосов
/ 15 октября 2008

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

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

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

Ответы [ 4 ]

14 голосов
/ 16 октября 2008

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

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

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

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

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.find_by_login ...», миграция вызовет исключение, которое является большой болью.

4 голосов
/ 15 октября 2008

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

2 голосов
/ 16 октября 2008

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

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

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

...