Ruby on Rails c нуля!

Миграции всегда были одной из основных «фишек» Ruby on Rails. В Rails 3.1 миграции приобретают еще один козырь, который упрощает процесс поддержки логики в up и down методах миграции. Если вам нужно немного восстановить свои знания о миграциях, я рекомендую прочитать официальный .

Давайте начнем с разбора примера миграции из Rails 3.0:

#db/migrate/20110505090317_create_posts.rb
class CreatePosts < ActiveRecord::Migration
  def self.up
    create_table :posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end

  def self.down
    drop_table :posts
  end
end

Эта миграция создает в базе данных таблицу posts с двумя полями — title и body тип хранимых данных в которых соответственно string и text. Хэлпер timestamps создает поля типа datetime — created_at и updated_at. Для отката этой миграции нам просто необходимо удалить таблицу posts. Метод .down как раз и занимается откатом миграции — удалением таблицы posts. Когда Rails использует миграцию, миграция запускает метод .up. Для отката миграции (которая выполняется командой rake db:rollback) миграция выполняет метод .down.

Глядя на эту миграцию возникают два вопроса:

- Почему именно методы класса, вместо методов экземпляра класса?
- Для простых случаев почему бы не объявить только метод выполнения миграции и защитить миграцию от отката?

Замечательный человек Аарон Петерсон думает так же и решил упросить миграции.

Знакомьтесь, упрощенные миграции!

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

#console
$ rails g model Post title:string body:text

#db/migrate/20110505084530_create_posts.rb
class CreatePosts < ActiveRecord::Migration
  def change
    create_table :posts do |t|
      t.string :title
      t.text :body

      t.timestamps
    end
  end
end

По умолчанию Rails 3.1 будет генерировать миграции для моделей использую метод #change, который теперь будет хранить логику ранее хранимую в методе .up. Когда запускается rollback, Rails будет выполнять откат миграции просто оценивая инструкции в «up». Следуем дальше, выполняем миграции и затем делаем откат. Выполняя все это, вы должны будете увидеть в консоли что-то вроде этого:

$ rake db:migrate
(in /home/rohit/code/migrahedron)
==  CreatePosts: migrating ====================================================
— create_table(:posts)
-> 0.0012s
==  CreatePosts: migrated (0.0013s) ===========================================

$ rake db:rollback
(in /home/rohit/code/migrahedron)
==  CreatePosts: reverting ====================================================
— drop_table(«posts»)
-> 0.0007s
==  CreatePosts: reverted (0.0008s) ===========================================

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

Что на счет команд, которые не могут быть отменены?

Существуют определенные команды, как например remove_column, которые не могут быть автоматически отменены. Это так потому, что информация необходимая для повторного создания столбца не доступна в команде remove_column. Если Rails во время отката миграции столкнется с командой, которую откатить нельзя, то будет возвращена ошибка: ActiveRecord::IrreversibleMigration.

#db/migrate/20110505101449_remove_title_from_post.rb
class RemoveTitleFromPost < ActiveRecord::Migration
  def change
    remove_column :posts, :title
  end
end

Если вы попытаетесь сделать откат вышеприведенной миграции, то вы получите что-то вроде этого:

#console
$ rake db:rollback
(in /home/rohit/code/migrahedron)
==  RemoveTitleFromPost: reverting ============================================
rake aborted!
An error has occurred, this and all later migrations canceled:

ActiveRecord::IrreversibleMigration

(See full trace by running task with —trace)

Если вы хотите обработать подобные случаи вручную вы можете по прежнему объявлять методы #up и #down, почти как раньше.

up и down теперь методы экземпляра класса

Все, что нужно для приведения старых миграций в новый вид — это объявить методы #up и #down как методы экземпляра класса, просто удалите приемник self перед именами методов #up и #down:

#db/migrate/20110505101557_remove_title_from_post.rb
class RemoveTitleFromPost < ActiveRecord::Migration
  def up
    remove_column :posts, :title
  end

  def down
    add_column :posts, :title, :string
  end
end

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

Больше магии?

Если вы удивлены тем как определяются откаты миграций и в духе Жозе Валима желаете увидить всю магию Rails, я думаю, я предоставлю вам простое описание того, как Rails автоматически делает откат миграций.

Магия происходит в классе . Если вы объявляете метод #change в вашей миграции и запускаете миграцию, то код #change выполняется аналогично коду из #up.

Однако когда происходит откат миграции, запускается сгенерированный список реверсивных команд. Команды отката — это просто команды, которые выполняют противоположные действия по отношению к действиям команд миграций. Например, обратная команда для rename_table(old, new) это rename_table(new, old). Логика получения обратной команды предоставляется самим классом. Для тех команд, инверсии которых не могут быть созданы, вызывается исключительная ситуация ActiveRecord::IrreversibleMigration.

Оригинал статьи на английском:

 

Лучшая благодарность автору блога — ваши комментарии! Наши ошибку или неточность? — Пожалуйста, сообщите в комментариях.