Навигация
16.6. В чем заключаются слабые стороны миграций
Миграции страдают от одной серьезной проблемы. Лежащие в их основе DDL-операторы, обновляющие схему базы данных, не обладают свойствами транзак¬ции. Rails здесь ни при чем — большинство баз данных просто не поддерживают откаты create table, alter table и других DDL-инструкций.
Рассмотрим миграцию, с помощью которой делается попытка добавить к I данных две таблицы.
class ExampleMigration < ActiveRecord:Migration
def self.up
create_table :one do ... end
create_table :two do ... end
end
def self.down
drop_table :two drop_table :one
end
end
При нормальном развитии событий метод up добавит таблицы onentwo.ai тод down их удалит.
А что, если с созданием второй таблицы возникнут проблемы? Получится, ч в базе данных появится таблица one, но не будет таблицы two. Мы можем < виться с любой возникшей проблемой с помощью миграции, но в данном сд мы не сможем ее применить — если мы попытаемся это сделать, то потерпим i ско, поскольку таблица one уже существует.
Мы можем попытаться осуществить откат миграции, но из этого тоже i не получится: поскольку сама миграция целиком не сработала, версия схемы! зы данных не прошла обновление, поэтому Rails не будет осуществлять пои ее отката. В такой ситуации вы могли бы оставить подобные попытки, вру изменить информацию о схеме и удалить таблицу one. Но, наверное, так . не стоит. В подобных обстоятельствах мы рекомендуем просто удалить всю { данных, создать ее заново и применить к ней существующие миграции, дящие ее к требуемому на данный момент состоянию. Вы ничего не поте и будете знать, что имеете схему, выстроенную в последовательности версий.;
Все эти разговоры наводят на мысль, что миграции опасно применять к < данных в уже работающем программном продукте. Я советую перед примене миграций как минимум создавать резервную копию базы данных, наход в эксплуатации. Как применять миграции к рабочим базам данных, вам пр ит исследовать самостоятельно — этой темы я больше касаться не хочу.