Rails: вопросы по миграции

Question

Я новичок в Ruby on Rails, я знаю вещи, но теперь мне приходится сталкиваться с реальными проектами и делать вещи. Я написал эту миграцию:

  def change
    change_table :societies do |t|
      ## Database authenticatable
        t.string :email,              :null => false, :default => ""
        t.string :encrypted_password, :null => false, :default => ""

        ## Recoverable
        t.string   :reset_password_token
        t.datetime :reset_password_sent_at

        ## Rememberable
        t.datetime :remember_created_at

        ## Trackable
        t.integer  :sign_in_count, :default => 0
        t.datetime :current_sign_in_at
        t.datetime :last_sign_in_at
        t.string   :current_sign_in_ip
        t.string   :last_sign_in_ip

        # Token authenticatable
        t.string :authentication_token

И когда я пытался откатить его, я получаю ActiveRecord :: IrreversibleMigration Я знаю, где ошибка, и мой вопрос:

Могу ли я просто изменить примененную миграцию, чтобы исправить ошибку, а затем повторно запустить rake db: migrate?
O мне нужно изменить миграцию с помощью методов вверх / вниз, отменить миграцию и затем выполнить миграцию снова?
Или, может быть, я бы бросил таблицу с новой миграцией и заново создал ее? Какая лучшая практика?

Answer 1

TL; DR

• Если изменение еще не введено в действие, обычно вы можете избежать изменения миграции.
• Рекомендуется сохранять файлы миграции максимально чистыми и ограниченными по количеству и объему.
• Если изменение уже введено в эксплуатацию или если вы изменили его, это усложнит жизнь другим разработчикам, добавьте дополнительные миграции, чтобы исправить ошибочные предыдущие миграции.
• Вы можете быть немного слабее с этими рекомендациями, если вы только добавляете функциональность (возможность отменить миграцию), не меняя того, что первоначально миграция делала.

Полный ответ:

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

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

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

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

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

Имея это в виду, скажем, следуя вышеприведенным рекомендациям, вы уже решили, что все в порядке, чтобы изменить ваши миграции. Затем, чтобы ответить на ваши конкретные вопросы:

Могу ли я просто изменить примененную миграцию, чтобы исправить ошибку, а затем повторно запустить rake db: migrate?

Нет, после запуска миграции его идентификатор сохраняется в базе данных, и он не будет запускаться снова, даже если файл изменится.

Или мне нужно изменить миграцию методами up / down, отменить миграцию и затем выполнить миграцию снова?

Вы должны изменить миграцию методами up / down, да. Но, как вы уже сказали, вы не можете вернуть миграцию официальным способом. Вместо этого вы можете либо заново загрузить свою среду с чистого листа, либо вы можете вручную отменить миграцию, используя sql запросы (не забудьте также удалить связанный идентификатор из таблицы миграции). Затем повторно запустите миграцию.

Или, может быть, я бы отбросил таблицу с новой миграцией и заново создал ее?

Не делайте этого, пока вас не заставят (и даже при этом будьте осторожны, чтобы при запуске его в производстве вы случайно не уничтожили данные во время этого процесса!).

Наконец, следует отметить, что если единственное изменение, которое вы вносите в файл миграции, - это разделение «изменения» на методы «вверх / вниз», а часть «вверх» точно такая же после вашей модификации, Вы даже можете избежать обхода вышеуказанных рекомендаций, потому что это не повредит другим разработчикам (теперь они могут просто откатить то, что раньше не могли откатить). Но в этом случае будьте осторожны - вы не хотите облажаться и случайно даже немного измените метод up.

Answer 2

Вы не можете использовать изменения с таблицей изменений. Так что вам понадобится метод вверх и вниз. Проверьте http://guides.rubyonrails.org/migrations.html для получения более подробной информации, но change_table не может быть легко изменен, поэтому rails не может сделать это автоматически для вас. Требуется дополнительная информация о том, как сделать это правильно.

Список вещей, которые вы можете использовать изменить со страницы выше:

• add_column
• add_index
• add_timestamps
• create_table
• remove_timestamps
• rename_column
• rename_index
• rename_table

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

Answer 3

Согласно Руководству по миграции Rails :

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