Как правило, это плохая идея ссылаться на ваши модели из ваших миграций, как это. Проблема в том, что миграции выполняются по порядку и изменяют состояние базы данных по мере их прохождения, но ваши модели вообще не имеют версий. Нет никакой гарантии, что модель, существовавшая на момент написания миграции, будет совместима с кодом миграции в будущем.
Например, если в будущем вы измените поведение атрибутов is_active
или is_live
, эта миграция может прерваться. Эта старая миграция будет выполняться первой для нового кода модели и может завершиться ошибкой. В вашем базовом примере это может не появиться, но это сожгло меня при развертывании до того, как поля были добавлены, а проверки не могли выполняться (я знаю, что ваш код пропускает проверки, но в целом это проблема).
Мое любимое решение — выполнять все миграции такого рода с помощью простого SQL. Похоже, вы уже подумали об этом, поэтому я предполагаю, что вы уже знаете, что там делать.
Другой вариант, если у вас есть какая-то запутанная бизнес-логика или вы просто хотите, чтобы код выглядел более Railsy, — включить базовую версию модели в том виде, в каком она существует на момент написания миграции, в сам файл миграции. Например, вы можете поместить этот класс в файл миграции:
class Group < ActiveRecord::Base
end
В вашем случае этого, вероятно, достаточно, чтобы гарантировать, что модель не сломается. Предполагая, что active
и live
являются булевыми полями в таблице в настоящее время (и, таким образом, будут всегда, когда эта миграция будет выполняться в будущем), вам вообще не потребуется никакого дополнительного кода. Если у вас есть более сложная бизнес-логика, вы можете включить ее в эту версию модели для миграции.
Вы даже можете подумать о том, чтобы скопировать целые методы из вашей модели в миграционную версию. Если вы это сделаете, имейте в виду, что вы также не должны ссылаться на какие-либо внешние модели или библиотеки в своем приложении, если есть шанс, что они изменятся в будущем. Сюда входят гемы и, возможно, даже некоторые базовые классы Ruby/Rails, потому что изменения в гемах, нарушающие API, очень распространены (я смотрю на вас, Rails 3.0, 3.1 и 3.2!).
person
Jim Stewart
schedule
18.03.2013