Как вы справляетесь с критическими изменениями в миграции Rails?

Question

Допустим, я начинаю с этой модели:

class Location < ActiveRecord::Base
  attr_accessible :company_name, :location_name
end

Теперь я хочу реорганизовать одно из значений в связанную модель.

class CreateCompanies < ActiveRecord::Migration
  def self.up
    create_table :companies do |t|
      t.string :name, :null => false
      t.timestamps
    end

    add_column :locations, :company_id, :integer, :null => false
  end

  def self.down
    drop_table :companies
    remove_column :locations, :company_id
  end
end

class Location < ActiveRecord::Base
  attr_accessible :location_name
  belongs_to :company
end

class Company < ActiveRecord::Base
  has_many :locations
end

Это все работает нормальново время разработки, так как я делаю все шаг за шагом;но если я попытаюсь развернуть его в своей промежуточной среде, у меня возникнут проблемы.

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

Кто-нибудь еще имел дело с этой проблемой?Смирился ли я с тем, чтобы разделить развертывание на несколько этапов?

ОБНОВЛЕНИЕ Кажется, я ошибаюсь;при переносе среды коллег мы столкнулись с проблемами, но их обновление без проблем.Моя вина.Я отмечу ответ @ noodl как ответ, чтобы похоронить это, его сообщение в любом случае является хорошим советом.

Answer 1

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

Это не означает, что вы не можете использовать объекты вашей модели, просто вы не должны использовать версии, найденные в любой версии вашего кода, установленной при выполнении конкретной миграции.

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

#20110111193815_stop_writing_fragile_migrations.rb
class StopWritingFragileMigrations < ActiveRecord::Migration
  class ModelInNeedOfMigrating < ActiveRecord::Base
    def matches_business_rule?
      #logic copied from model when I created the migration
    end
  end
  def self.up
    add_column :model_in_need_of_migrating, :fancy_flag, :boolean, :default => false

    #do some transform which would be difficult for me to do in SQL
    ModelInNeedOfMigrating.all.each do |model|
      model.update_attributes! :fancy_flag => true if model.created_at.cwday == 1 && model.matches_business_rule?
      #...
    end
  end

  def self.down
    #undo that transformation as necessary
    #...
  end
end

Answer 2

Какую ошибку вы получаете при запуске миграции?С вами все будет хорошо, если ваши файлы rake и миграции не используют ваши модели (и они не должны).

Вы также захотите изменить порядок строк drop_table и remove_column в self. вниз вашей миграции.