Почему методы вверх и вниз не создаются с моим подклассом ActiveRecord :: Migration?

Question

Я читаю Rails 3 в действии и дословно следую командам.Однако, когда я запускаю команды

rails new things_i_bought
cd things_i_bought
bundle install
rails generate scaffold purchase name:string cost:float

В книге сказано, что я должен получить этот код:

class CreatePurchases < ActiveRecord::Migration
          def self.up #not created in my code
            create_table :purchases do |t|
              t.string :name
              t.float :cost
              t.timestamps
            end
end
          def self.down # not created in my code
            drop_table :purchases
end
 end

Вместо этого я получаю этот код:

class CreatePurchases < ActiveRecord::Migration
  def change
    create_table :purchases do |t|
      t.string :name
      t.float :cost

      t.timestamps
    end
  end
end

Почемуметоды класса вверх и вниз не создаются для меня?Я использую рельсы 3.1.1 и ruby ​​1.9.2.

Answer 1

спасибо за чтение моей книги!

Как уже объясняли JacobM и dbalatero, это новая функция в Rails 3.1. Эта особенность была добавлена ​​Аароном Паттерсоном как способ упростить синтаксис миграции. В более ранних версиях Rails вы должны были делать, как показано в книге:

class CreatePurchases < ActiveRecord::Migration
  def self.up
    create_table :purchases do |t|
      t.string :name
      t.float :cost
      t.timestamps
    end
  end

  def self.down
    drop_table :purchases
  end
end

Но это своего рода повторение. Аарон создал синтаксис переноса, который выглядит хорошо и проще, вызывая только методы, необходимые для переноса вперед, но также разрешая переносы назад (также известные как «откат»). Та же самая миграция, написанная с помощью синтаксиса Rails 3.1, такова:

class CreatePurchases < ActiveRecord::Migration
  def change
    create_table :purchases do |t|
      t.string :name
      t.float :cost
      t.timestamps
    end
  end
end

Таким образом, когда эта миграция запускается «вперед», Rails создаст таблицу покупок с полями. Когда вы откатите его назад (или запустите «назад»), Rails узнает, что нужно сбросить таблицу.

Однако этот синтаксис не совсем совершенен, и у вас возникнут проблемы с такими методами, как change_column. Когда это происходит, лучше всего придерживаться определения методов def up и def down в миграциях:

class CreatePurchases < ActiveRecord::Migration
  def up
    change_column :purchases, :cost, :integer
  end

  def down
    change_column :purchases, :cost, :float 
  end
end

Это потому, что в этом примере Rails не будет знать, как переключить его обратно на предыдущий тип. Я надеюсь, что это объясняет это лучше!

Answer 2

Это новая функция в Rails 3.1 . Для изменений, которые Rails может выяснить, как выполнить обратное изменение, таких как создание таблицы, вы просто создаете метод «change» с кодом, который должен был бы быть «вверх», и он выясняет, как сделать «down» самостоятельно .

Вы также можете определить методы «вверх» и «вниз» самостоятельно - для некоторых изменений (таких как удаление столбца) Rails не сможет это выяснить - но синтаксис немного другой; это не просто def up вместо def self.up (теперь это методы экземпляров вместо методов классов).

Answer 3

Я полагаю, что в новых Rails 3.1 методы миграции баз данных знают о том, как выполнять миграцию вверх / вниз.

Поэтому, если вы определите метод def change, он попытаетсяиспользуйте эти самосознательные методы: в этом случае create_table знает, что нужно сделать DROP TABLE в контексте down, и CREATE TABLE в контексте up.

Если вы хотите использовать старый стильвы, вероятно, можете продолжать использовать его и определить свои собственные self.down и self.up методы, как описано в книге.

Редактировать: вот ссылка на сообщение в блоге об этом, называемое «Обратимыми миграциями»: http://www.edgerails.info/articles/what-s-new-in-edge-rails/2011/05/06/reversible-migrations/index.html