Миграции в framework выполняются транзакционно или нет
В Yii 2 есть механизм миграций. По сути миграции в БД это изменение структуры.
name – параметр принимающий имя миграции
После выполнения команды будет создан класс:
В метод up() содержится код, который должен быть выполнен при накатывании миграции. В методе down() содержится код, который выполнится при откате миграции. Пример миграции:
Данная миграция создаёт две таблицы и два внешних ключа.
Для создания таблицы используется метод createTable() принимающий два обязательных параметра, имя таблицы и масив описывающий свойства полей таблицы.
Для создания внешних ключей используются методы createIndex() для создания индекса, принимающий три параметра: имя индекса, имя таблицы и имя поля. И метод addForeignKey() принимающий семь параметров: имя внешнего ключа, имя таблицы и имя поля к которой добавляется ключ, имя таблицы и имя поля на которые ссылается ключ, стратегии при удалении и обновлении.
Для применения миграций используется команда:
Для применения нескольких миграций используется команда:
где 2 – число применяемых миграций
Для применения определённой версии миграции используется команда:
где 141018_180924 – timestamp миграций
Команда для отката миграции
[step] – количество отменяемых миграций
Для повторного применения миграции применяется команда
[step] – количество повторно применяемых миграций
Просмотр примененных миграций:
[limit] – количество выводимых записей
Просмотр списка новых миграций, которые ещё не были применены:
[limit] – количество выводимых записей
15 комментариев
Александр
Dec 10, 2014 @ 14:03:44
А зачем создаётся таблица “tbl_migration”?
Georgy Spack
Dec 11, 2014 @ 23:14:19
Таблица содержит информацию об истории миграций.
Андрей
Mar 31, 2015 @ 09:42:37
С tbl_migration всё ясно, а как быть с самими таблицами которые миграция должна создать, она что их создаёт не в бд а в файловой системе? или нужно что-то где перенастроить. В конфиге всё указано нормально.
Georgy Spack
Mar 31, 2015 @ 09:50:42
Миграция может создавать таблицы, а может изменять уже имеющиеся. Производиться изменения будут в БД. Если Вам нужно создавать таблицу, тогда в теле метода public function up() пишите запрос на создание таблицы как это приведено в примере статьи:
$this->createTable('>', [
'id' => Schema::TYPE_PK,
'title' => Schema::TYPE_STRING . ' NOT NULL',
], $tableOptions);
Ещё примеры миграций Вы можете поглядеть тут
Karen
Feb 12, 2015 @ 11:09:43
Georgy Spack
Feb 14, 2015 @ 09:06:28
Спасибо Karen, действительно safeUp лучше, он гарантирует целостность в случае неудачи одного из запросов.
Дмитрий
Oct 21, 2015 @ 12:31:07
глюк словил при миграциях в уйй2. а точнее транзакция не откатывает взад!
ответ по миграциям прост… Муйскуль не поддерживает транзакции мета-данных… коими являются создание бд…
в случае подения он не откатит созданные таблицы
Georgy Spack
Oct 21, 2015 @ 21:44:22
Это всё же к yii2 мало относится. В MySQL это поведение описано: Statements That Cannot Be Rolled Back
Дмитрий
Oct 22, 2015 @ 05:56:44
К тому что в MySQL safeUp лучше только при определенных операциях (вставках например). При создании новых таблиц гарантии целостности с safeUp нет. И это нужно понимать.
ksetrin
Apr 18, 2015 @ 17:01:07
Почему используется запись ‘>’ вместо ‘category’? В чем разница?
Georgy Spack
Apr 18, 2015 @ 22:40:24
> такая запись учитывает префикс таблиц
German
Aug 26, 2015 @ 15:20:39
Макс
Jan 11, 2017 @ 16:59:40
Все классно только 141018_180924 – это не timestamp как вы пишите.
Вот шаблон генерации имени миграции:
m_
Макс
Jan 11, 2017 @ 17:01:12
редактор срезал дублирую
mYYMMDD_HHMMSS_Name
Georg Spack
Jan 24, 2017 @ 23:28:57
Это именно Timestamp. Timestamp (дословно с англ. — «печать/отметка времени») — это последовательность символов или закодированной информации, показывающей, когда произошло определённое событие. Обычно показывает дату и время (иногда с точностью до долей секунд).
Примечание: Миграции доступны с версии 1.1.6.
Как и исходный код, структура базы данных изменяется в процессе разработки и поддержки приложения. К примеру, во время разработки может понадобиться добавить новую таблицу или уже после размещения приложения на сервере добавить индекс или столбец. При этом важно отслеживать изменения в структуре базы данных (называемые миграциями) также, как мы делаем это для нашего исходного кода. Если исходный код и база данных не соответствуют друг другу, скорее всего, всё приложение не будет работать. Именно поэтому в Yii есть поддержка миграций, позволяющая отслеживать изменения в базе данных, применять миграции или откатывать уже применённые.
Ниже приведён пошаговый процесс использования миграций при разработке:
- Иван создаёт новую миграцию (например, создающую новую таблицу).
- Иван заливает её в систему контроля версий (SVN, GIT или другую).
- Андрей обновляется из системы контроля версий и получает новую миграцию.
- Андрей применяет миграцию к своей локальной базе данных.
В Yii управление миграциями производится через консольную команду yiic migrate , которая поддерживает создание новых миграций, применение, откат и повторное применение миграций, просмотр истории миграций и новых миграций.
Примечание: При работе с командой migrate рекомендуется использовать yiic приложения (то есть после cd path/to/protected ), а не yiic из директории framework . Убедитесь, что директория protected\migrations существует и доступна для записи. Также проверьте настройки соединения с базой данных в protected/config/console.php .
6. Просмотр информации о миграциях ¶
Кроме применения и отката миграций, инструмент миграций может отображать историю миграций, а также новые, ещё не применённые миграции.
Здесь параметр limit указывает количество отображаемых миграций. Если limit не указан, показываются все миграции.
Первая команда показывает уже применённые миграции, вторая — миграции, которые ещё не были применены.
Налейте чашечку кофе, вам нужно прочитать всю статью
В командной работе проблемы в основном связаны со слиянием миграций, созданных двумя разработчиками в их локальных базах данных. В то время как шаги, для решения этих проблем довольно просты, они требуют, четкого представления о том, как работают миграции. Пожалуйста, не торопясь, прочитайте внимательно всю статью.
Некоторые общие принципы
Прежде чем мы углубимся в то, как управлять слиянием миграций создаваемых несколькими разработчиками, вот некоторые общие принципы.
Каждый член команды должен иметь локальную базу данных для разработки
Механизм миграций использует таблицу __MigrationsHistory, чтобы хранить список миграций, которые были применены к базе данных. Если у вас в команде несколько разработчиков генерируют миграции, то при попытке работы с одной и той же базой данных (и, следовательно, с одной таблицей __MigrationsHistory) механизм миграций может испытать затруднения.
Конечно, если у вас есть члены команды, которые не создают миграции, то проблем с работой с центральной базой данных для разработки не возникнет.
Избегайте автоматических миграций
Суть в том, что автоматические миграции изначально хорошо выглядят в командной работе, но в действительности они просто не работают. Если вы хотите знать причину, продолжайте читать статью, иначе вы можете перейти к следующей главе.
Автоматические миграции позволяют обновляться схеме базы данных в соответствии с текущей моделью без необходимости создания файлов с кодом миграции (code-based миграции).
От переводчика: в оригинальной статье размещены 2 скринкаста, рекомендую ознакомиться
Принципы работы механизма миграций
Ключ к успешному использованию миграций в команде состоит в базовом понимании, как механизм миграции отслеживает и использует информацию о модели для обнаружения изменений.
Первая миграция
При добавлении первой миграции к вашему проекту, вы запускаете что-то вроде Add-Migration First в Package Manager Console. Внизу изображены шаги, которые выполняет эта команда.
На основе кода рассчитывается текущая модель (1). Затем с помощью model differ рассчитываются необходимые объекты базы данных (2) — поскольку это первая миграция, model differ для сравнения использует пустую модель. Необходимые изменения передаются в генератор кода для создания необходимого кода миграции (3), который затем добавляется в решение Visual Studio (4).
В дополнение к коду миграции, который хранится в главном файле, механизм миграции также создает дополнительные code-behind файлы. Это файлы метаданных, которые используются механизмом миграций и вы не должны их изменять. Один из этих файлов — это файл ресурсов (.resx), который содержит снимок модели на момент создания миграции. В следующем разделе вы увидите, как он используется.
В этот момент можно выполнить Update-Database, чтобы применить изменения к базе данных, а затем начать реализовывать остальные части вашего приложения.
Последующие миграции
Внесем некоторые изменения в модель — в нашем примере мы добавим свойство Url в класс Blog. Затем необходимо выполнить команду Add-Migration AddUrl, чтобы создать миграцию для применения соответствующих изменений в базе данных. Внизу изображены шаги, которые выполняет эта команда.
Так же, как в прошлый раз, текущая модель рассчитывается из кода (1). Тем не менее, на этот раз есть существующие миграции, и предыдущая модель извлекается из последней миграции (2). Эти две модели сравниваются, чтобы найти необходимые изменения в базе данных (3), и затем процесс завершается, как и раньше.
Этот же процесс используется для всех следующих миграций, которые добавляются к проекту.
Зачем запариваться со снимками модели?
- Это позволяет вашей базе данных отличаться от модели EF. Эти изменения могут быть сделаны непосредственно в базе данных, или вы можете изменить scaffolded код в ваших миграциях, чтобы внести изменения. Вот несколько примеров этого на практике:
- Вы хотите добавить Inserted и Updated столбцы к одной или более таблиц, но вы не хотите, чтобы их включать в модель EF. Если бы механизм миграций смотрел на базу данных, он бы постоянно пытался удалить эти столбцы каждый раз, когда вы генерируете код миграции. Используя снимок модели, EF будет обнаруживать только нужные изменения в модели.
- Вы хотите изменить тело хранимой процедуры, используемой для обновлений некой отладочной информации. Если бы механизм миграций смотрел на хранимую процедуру в БД, он бы постоянно пробовал сбросить её назад к определению. При использовании снимка модели, EF будет генерировать код для изменения хранимой процедуры, когда вы измените процедуру в модели EF
- Эти же принципы применимы при добавлении дополнительных индексов, в том числе дополнительных таблиц в базе данных, маппинг EF к DB View и т.д.
Что вызывает вопросы при командной работе
Процесс, рассмотренный в предыдущем разделе, прекрасно работает, если вы единственный разработчик, который работает над приложением. Он также хорошо работает в команде, если вы единственный человек, который вносит изменения в модель. В этом случае вы можете вносить изменения в модель, генерировать миграции и отправлять их в систему контроля версий. Другие разработчики могут получать такие изменения и запускать Update-Database, чтобы обновлять схему.
Проблемы начинают возникать, когда у вас несколько разработчиков, которые вносят изменения в модель EF и отправляют их в систему контроля версий. Чего EF не хватает, так это первоклассного способа объединять локальные миграции с миграциями, других разработчиков отправленных в систему контроля версий после последней синхронизации.
Пример слияния конфликта
Сначала давайте рассмотрим конкретный пример слияния такого конфликта. Мы будем продолжать на примере, который рассмотрели ранее. В качестве отправной точки давайте предположим, что изменения от предыдущего раздела были проверены настоящим разработчиком. Мы будем отслеживать двух разработчиков, которые делают изменения в коде.
Мы будем отслеживать модель EF и миграции через ряд изменений. Оба разработчика синхронизируются через репозиторий в системе контроля версий, как показано на следующем рисунке.
Есть несколько проблем, например:
-
Хотя операция Update-Database будет применять миграции AddRating, она также будет показывать предупреждение:
Unable to update database to match the current model because there are pending changes and automatic migration is disabled…
Проблема в том, что снимок модели хранится в последней миграции (AddReader), которая пропускает свойство Rating в классе Blog (так как он не был частью модели, когда миграция была создана).2. Транзакционные миграции ¶
Информация: Данная возможность поддерживается, начиная с версии 1.1.7.
При применении сложных миграций для сохранения целостности данных требуется либо выполнить все запросы, либо, если запрос не выполнился, отменить предыдущие запросы. Для достижения этой цели можно использовать транзакции.
Можно начать транзакцию явно и заключить в неё весь код, меняющий базу данных:
А можно сделать это проще, реализовав метод safeUp() вместо up() и safeDown() вместо down() :
Yii при применении миграции начнёт транзакцию, а затем выполнит код в safeUp() или safeDown() . Если при этом возникнет какая-либо ошибка, произойдёт откат транзакции, то есть база вернётся в начальное состояние.
Примечание: Не все СУБД полностью поддерживают транзакции и не для всех выражений. В том случае, если поддержки транзакций нет, реализовывать надо up() и down() . В случае использования MySQL или MariaDB некоторые выражения SQL могут вызвать неявное применение транзакции. Смотрите документацию MySQL и MariaDB.
Глобальная конфигурация команды
В то время как опции командной строки позволяют нам на лету конфигурировать команду миграций, иногда требуется применить настройки раз и навсегда. К примеру, нам может понадобиться использовать другую таблицу для хранения истории миграций или использовать свой шаблон миграции. Это можно сделать, изменив настройки консольного приложения следующим образом:
Теперь при запуске команды migrate указанные выше настройки будут применены без ввода каких-либо дополнительных параметров.
Миграции — это незаменимый инструмент при совместной работе над проектом. Каждый разработчик меняет что-то в структуре БД. Остальным приходится делать те-же изменения в своей локальной базе. Какие изменения нужно внести? Какие изменения я уже применял в своей базе? Где найти изменения, что сделал в структуре БД другой программист? Всю головную боль на себя возьмет механизм миграций. А пользоваться им проще простого. Главное чтобы все разработчики, участвующие в проекте пользовались им.
-
Шаг 1: настраиваем коннект к БД — миграции будут запускаться из консоли, поэтому нужно настроить protected/config/console.php , прописав там коннект к базе в настройках компонента db
В классе миграции существует два основных метода: up — выполняется при применении миграции, а down — в случаи отката. Если откат не возможет, метод down должен вернуть false
Пишем в данном классе, те действия по изменению БД, которые мы хотели сделать. Доступные методы: execute, insert, update, delete, createTable, renameTable, dropTable, truncateTable, addColumn, dropColumn, renameColumn, createIndex и другие можно посмотреть в классе CDbMigration.Думаю вы заметили, что описание типов данных столбцов отличается от стандарта SQL. Это сделано для того, чтобы механизм миграций мог работать на различных типах баз данных. В Yii доступны следующие типы столбцов таблицы:
Теперь после каждого получения свежей версии с репозитория, нужно запускать эту команду для синхронизации структуры базы. Согласитесь — очень просто и легко.
Для того, чтобы откатить миграцию нужно выполнить командуЗа рамками данной статьи остались такие команды как redo, migrate to, mark и другие. Так же в статье не раскрыта тема транзакционных миграций и методов safeUp safeDown. Но то, что описано уже достаточно чтобы начать пользоваться миграциями и понять, насколько же они удобны.
1. Создание миграций ¶
Для создания новой миграции (например, создающей таблицу для новостей), мы должны ввести в консоли:
Обязательный параметр name должен содержать очень краткое описание миграции (например, create_news_table ). Как будет показано далее, этот параметр используется как часть имени класса миграции, поэтому использовать можно только буквы, цифры и знаки подчёркивания.
Приведённая команда создаст в директории protected/migrations файл m101129_185401_create_news_table.php , содержащий следующее:
Стоит отметить, что имя класса совпадает с именем файла и строится как m_ , где — это время создания миграции в UTC (в формате yymmdd_hhmmss ), а — то, что передано в параметре name команды.
Метод up() должен содержать код, выполняющий миграцию, а метод down() может содержать код, отменяющий сделанное в up() .
Иногда реализовать down() не получается. К примеру, если в up() из таблицы удаляются данные, в down() вернуть их не получится. В этом случае миграция называется необратимой, что означает невозможность возврата к предыдущему состоянию базы данных. В приведённом выше коде метод down() возвращает false . Это означает невозможность отката миграции.
Информация: Начиная с версии 1.1.7, если метод up() или метод down() возвращают false , все последующие миграции не будут применены. В 1.1.6 для этого было необходимо выкинуть исключение.
Рассмотрим в качестве примера миграцию, создающую таблицу с новостями.
Базовый класс CDbMigration предоставляет набор методов для работы с данными и структурой базы данных. К примеру, при помощи CDbMigration::createTable можно создать новую таблицу, а CDbMigration::insert добавит строку с данными. Все эти методы используют подключение к базе данных, возвращаемое CDbMigration::getDbConnection(), что по умолчанию эквивалентно Yii::app()->db .
Решение конфликтов слияния
Хорошей новостью является то, что не очень трудно сливать миграции вручную, если у вы понимаете, как работает миграция. Так что если вы пропустили начало этой статьи… извините, нужно вернуться назад и прочитать первую часть статьи сначала!
Есть два варианта, самый простой заключается в создании пустой миграции, который имеет правильный снимок модели. Второй вариант заключается в обновлении снимка в последней миграции, чтобы иметь правильный снимок модели. Это немного сложнее и этот вариант не может быть использован в каждом случае. Его преимущество в том, что он не предполагает добавление дополнительной миграции.
Вариант 1: Добавление пустой «merge» миграции
В этом варианте мы генерируем пустую миграцию исключительно для того, чтобы последняя миграция имела правильный снимок модели, хранящийся в нем.
Следующий алгоритм может быть использован с момента, когда появляются изменения, которые должны быть синхронизированы с системой контроля версий.
- Убедитесь, что все изменения модели в вашей локальной кодовой базе были сохранены в миграции. Этот шаг гарантирует, что вы не пропустите никакие важные изменения, когда придет время создания чистой миграции
- Синхронизируйте код с системой контроля версий
- Выполните Update-Database для применения любых новых миграций, сделанных другими разработчиками.
Примечание: если вы не получите каких-либо предупреждений во время выполнения Update-Database, то не было никаких новых миграций от других разработчиков и нет необходимости выполнять дополнительные слияния. - Выполните Add-Migration -ignorechanges (например, add-migration merge -ignorechanges). Эта команда создает миграцию со всеми метаданными (включая снимок текущей модели), но будет игнорировать любые изменения, которые он обнаружит при сравнении текущей модели со снимком последний миграции (то есть вы получите пустые Up и Down методы).
- Продолжайте разработку, или отправляйте изменения в систему управления версий (после запуска модульных тестов конечно).
Вариант 2: Обновление снимка модели последней миграции
Этот вариант очень похож на вариант 1, но удаляет лишнюю пустую миграцию.
Этот подход возможен, если последняя миграция существует только локально и до сих пор не отправлен в систему контроля версий (т.е. последняя миграция была создана пользователем выполняющим слияние). Редактирование метаданных миграций, которые применены у других разработчиков, или даже хуже — применены к боевой базе данных, может привести к неожиданным побочным эффектам. В процессе мы будем выполнять откат последней миграции в нашей локальной базе данных и повторно применять с обновленными метаданными.
Пока последняя миграция находится локально, нет никаких ограничений на количество или порядок миграций.
Те же шаги применимы, при нескольких миграциях от нескольких различных разработчиков.Следующий алгоритм может быть использован, когда появляются изменения, которые должны быть синхронизированы с системой контроля версий.
- Убедитесь, что все изменения модели в вашей локальной кодовой базе были сохранены в миграции.
Этот шаг гарантирует, что вы не пропустите никакие важные изменения, когда придет время создания чистой миграции. - Синхронизируйте код с системой контроля версий.
- Выполните Update-Database для применения любых новых миграций, сделанных другими разработчиками.
Это действие откатывает базу данных назад на состояние предпоследней миграции — фактически,
где не была применена последняя миграция на базу данных.Итого
Есть некоторые проблемы при использовании миграций Code First в команде. Тем не менее, общее представление о том работают миграции, и некоторые простые подходы к решению конфликтов слияния позволяют легко преодолеть эти проблемы.
Фундаментальной проблемой являются ошибочные метаданные, которые хранятся в последней миграции. Это позволяет Code First неправильно определять, что текущая модель и схема базы данных не совпадают и сгенерировать неправильный код для следующей миграции. Эта ситуация может быть исправлена путем генерации пустой миграции с правильной моделью, или обновления метаданных в последней миграции.
8. Настройка команды миграций ¶
Есть несколько способов настроить команду миграций.
5. Повторное применение миграций ¶
Повторное примение миграции производится путём последовательного отката и применения. Осуществить это можно следующей командой:
где необязательный параметр step указывает количество миграций, которые необходимо применить ещё раз. По умолчанию повторяется одна последняя миграция.
4. Откат миграций ¶
Для отката одной или нескольких последних применённых миграций можно воспользоваться следующей командой:
где необязательный параметр step задаёт количество миграций, которые надо откатить. По умолчанию откатывается одна последняя применённая миграция.
Как было описано ранее, не все миграции можно откатить. При попытке отката таких миграций будет выброшено исключение и процесс отката будет прерван.
Оставить комментарий
>Шаг 2: создаем файл миграции. Удостоверьтесь в том, что у вас существует папка protected/migrations
Откуда этот относительный путь отсчитывать?
У меня, например, в корневой папке («yii», там где vendor, web, controllers, …) нет папки protected.Нет. У вас судя по структуре Yii2, а эта статья для Yii1.x. Вам сюда.
Проблемка.
В шабдоне миграции предусмотрен механизм транзакций (для БД которые поддерживают) . Это функции safeUp, safeDown.
Однако не прошло. Консоль сообщила успешное прохождение, но реально в базе требуемой таблицы не оказалось.MySQL не поддерживает транзакции для изменения схемы. Т.е любое изменение структуры таблиц, ключей, индексов и тп в MySQL сразу неявно завершает транзакцию.
Как отменить(down) миграцию которая находится где-то в середине в истории миграции?
Откатить все миграции которые были после той, что нужно отменить, включая ту что хотите отменить, и накатить снова все миграции после той что отменили. Вдруг последующие миграции используют таблицы/столбцы что создавались этой? Последовательным применением всех последующих миграций вы это и проверите.
Миграции являются удобным инструментом для изменения структуры базы данных и поддержания ее в актуальном состоянии.
Yii2 поддерживает миграции из коробки. Использование миграций подробно описано в документации. Управление миграциями осуществляется из командной строки.
В статье описывается использование миграций для управления несколькими схемами БД. Как оказалось, это совсем несложно реализовать, но почему-то не нашел ни одного описания.
Нередко мне встречаются проекты, где используется более одной базы данных. В этом случае хочется управлять каждой базой в отдельности. Как вариант, можно в каждой миграции указывать, к какой базе данных ее применять, или явно указывать бд в каждом запросе. Но это не очень удобно и есть большая вероятность случайно накатить миграцию не на ту базу. Кроме того, таблица миграций все равно будет только в основной базе.К сожалению, готового решения не нашел, поэтому заглянем в код фреймворка и посмотрим, как работают миграции.
Команда yii migrate использует yii\console\controllers\MigrateControllerДля создания новой миграции используется шаблон migration.php
Все миграции наследуются от yii\db\Migration.
1. Для начала переопределяем базовый класс миграции для каждой БД. В папке components создаем классы CustomMigrationDb и CustomMigrationDb2
CustomMigrationDb2.php
2. В папке \views\migrations создаем файлы migration_db.php и migration_db2.php — шаблоны для новых миграций. Достаточно скопировать базовый шаблон и поменять базовый класс на те, что мы только что создали.migration_db2.php
3. Теперь создаем контроллеры. В папке commands создаем классы MigrateDbController и MigrateDb2Controller. Наследуем их от yii\console\controller\MigrateController.
MigrateDb2Controller.php
Здесь указываем базу данных, в которой будет создана таблица с миграциями, шаблон для создания новых миграций и путь до папки с миграциями.4. Отключаем стандартный yii migrate, вместо него будем использовать один из созданных контроллеров. Для этого добавим в файл \config\console.php следующий код:
UPD: zvirusz предлагает все контроллеры миграций вынести в controllerMap. Для этого нужно добавить в \config\console.php такой код.
В результате получаем независимые миграции для каждой БД. Миграции запускаются командами
yii migrate-db
yii migrate-db2Работают как обычные миграции. Новые миграции создаются в отдельных папках для каждой бд командами
yii migrate-db/create и
yii migrate-db2/createНаписал небольшое приложение для демонстрации. Выложил на github.
Спасибо за внимание.От переводчика: Прекрасная статья на понимание механизма миграций в Entity Framework 6 и путей решения конфликтов миграций при работе в команде. Оригинал статьи: Code First Migrations in Team Environments.
Эта статья предполагает, что вы знакомы с Entity Framework и с основами работы с ним. Иначе сначала вам нужно прочитать Code First Migrations, прежде чем продолжить.
3. Применение миграций ¶
Для того чтобы применить все новые миграции (то есть привести локальную БД в актуальное состояние), следует запустить следующую команду:
Команда покажет список всех новых миграций и, в случае утвердительного ответа, по очереди запустит метод up() в каждом классе миграции в порядке их создания.
После применения миграции в таблицу tbl_migration будет внесена соответствующая запись. Это позволяет узнать, какие миграции уже применены, а какие нет. Если таблица tbl_migration не существует, она будет создана автоматически в базе данных, указанной в компоненте db приложения.
Иногда требуется применить лишь одну или несколько новых миграций. Для этого можно использовать следующую команду:
При этом применятся три новых миграции. Вместо трёх можно указать любое количество применяемых миграций.
Также можно привести состояние базы данных к определённой версии:
В качестве параметра, указывающего версию, к которой надо привести базу данных, используется часть имени файла, соответствующая времени создании миграции. Если между последней применённой и указанной миграциями несколько миграций, то все они будут применены. Если указанная миграция уже применялась, то будет произведён откат всех миграций, применённых после неё (описано в следующем разделе).
Используя параметры командной строки
Команда миграций может быть настроена четыремя опциями:
interactive : использовать ли интерактивный режим. По умолчанию true, то есть при пременении миграции будет выводиться подтверждение. Если параметр выставлен в false, то миграции можно применить в фоновом режиме.
migrationPath : указывает директорию, в которой хранятся все файлы миграций. Путь должен указываться в формате псевдонима, и соответствующая ему директория должна существовать. Если параметр не указан, будет использована поддиректория migrations , находящаяся внутри директории с приложением;
migrationTable : указывает имя таблицы в базе данных, которая хранит историю миграций. Значение по умолчанию равно tbl_migration . Структура таблицы следующая: version varchar(255) primary key, apply_time integer ;
connectionID : указывает идентификатор компонента базы данных. По умолчанию это 'db';
templateFile : указывает путь к файлу, который используется как шаблон для генерации классов миграций. Путь должен указываться как псевдоним (то есть как application.migrations.template ). Если путь не задан, будет использоваться внутренний шаблон. В шаблоне токен будет заменён именем класса миграции.
Для указания опций используется следующий формат:
К примеру, если необходимо мигрировать модуль forum , файлы миграций которого расположены в директории модуля migrations , можно воспользоваться следующей командой:
Стоит отметить, что при передаче через командную строку флагов, таких как interactive , необходимо использовать значения 1 или 0 :
7. Изменение истории миграций ¶
Иногда требуется изменить историю миграций так, чтобы текущая версия была заменена на указанную без применения или отката миграций. Часто это требуется при созданнии новой миграции. Для этого можно использовать следующую команду:
Эта команда очень похожа на yiic migrate to , но она лишь изменяет таблицу истории миграций до указанной версии без применения или отката самих миграций.
Читайте также:
- Вы хотите добавить Inserted и Updated столбцы к одной или более таблиц, но вы не хотите, чтобы их включать в модель EF. Если бы механизм миграций смотрел на базу данных, он бы постоянно пытался удалить эти столбцы каждый раз, когда вы генерируете код миграции. Используя снимок модели, EF будет обнаруживать только нужные изменения в модели.