Миграции в Yii
30 ноября 2010
Вот и готова ожидаемая многими возможность — миграции.
Миграции очень важны для командной разработки, когда постоянно меняется не только код, но и структура базы данных. Чтобы каждый не применял руками изменения остальных членов команды и существуют миграции.
Как происходит типичная работа с миграциями?
Разработчик Андрей создаёт миграцию
yiic migrate create --name=create_news_table
Идёт в protected/migrations
и наполняет её полезным кодом:
class m20101129185401_create_news_table extends CDbMigration { public function up(){ $this->createTable('tbl_news', array( 'id' => 'pk', 'title' => 'string NOT NULL', 'content' => 'text', )); } /* public function down(){ } */ }
Тут можно использовать совершенно любой код, например, зачистить кеш или assets
.
Далее Андрей как-то передаёт миграцию Ивану. Через SVN, почтой или по FTP — не важно (лучше, конечно, через систему контроля версий). Иван применяет миграцию:
yiic migrate up
и спокойно работает с новым кодом.
Более подробное описание на русском будет на yiiframework.ru в ближайшее время (ну или, в крайнем случае, перед релизом).
Миграции будут включены в следующий релиз Yii, а пока можно поиграться с trunk-ом. Синтаксис может незначительно поменяться до релиза.
Комментарии RSS по email OK
действительно полезная возможность, очень хотелось бы чтобы была хорошо освещена в документации
Хотелось бы, чтобы миграции работали на уровне моделей. В частности AR. Было бы полезно для обновления сайтов на shared-хостингах.
Грубо говоря, чтобы была возможность закачать модели с обновленными конфигами на сайт, и модели сами прозрачно сравнили состояние таблиц БД с конфигами и обновили списки полей в таблицах, либо создали новые таблицы (ну или то, что требуется).
Не всегда ведь есть хостинг с SSH ))
Если нет SSH, то на помощь придёт web shell.
Ура! Наконец-то можно будет избавить от корявого расширения! Боюсь, только, релиз 1.1.6 будет не раньше января.
Это прекрасно ! Спасибо!
Ура! Давно ждал! Спасибо!!!
Я правильно понял, что саму "суть" миграции т.е. то, что изменилось - нужно описывать самостоятельно?
Поддержка добавления/удаления foreign keys не планируется?
xoma, все верно. Мне тоже это не очень нравится. Я обычно меняю напрямую таблицу, а не пишу сперва миграцию. Но одно радует, фреймворк идеет по верному пути, что я еле поспеваю следить за свежими функциями. Если б еще была интеграция миграций с гит или ссх, то будет вообще сказка.
xoma, да, описываете необходимые изменения, затем применяете их без ковыряния в базе вручную
Прошу прощения, опечатался, не ссх, а свн.
А если обновление должен выполнять человек, который вообще не имеет отношения к IT? Для него было бы хорошо просто закачать архив изменений на сайт через форму, и чтобы все заработало ))
Причем должно быть не важно, в какой версии сейчас находиться сайт на хостинге. И не факт, что там есть какие-то средства настроенной командной строки, SVN и пр. Может у человека просто установлен Денвер и там крутиться сайт, который мы ему сделали на Yii.
Ну это так, мечты...
Ekstazi, какого рода интеграция? Вешаемся на хук и просто запускаем
migrate up
при коммите. Или я что-то не понял?fduch2k, да.
Sam, Хы, вариант ) Просто я думал по-другому, запускаешь консольную комманду и автоматически коммитится в свн или гит.
Вообще все это выросло из расширения на github: https://github.com/pieterclaerhout/yii-dbmigrations От него был сделан форк и добавили возможность делать Constraints для InnoDB: https://github.com/mintao/yii-dbmigrations
Ну и я там небольшие фиксы сделал, но они уже в последнем форке есть. Автор изначального расширения pull request не удовлетворяет, неизвестно почему.
То что это войдет в ядро - это супер, мы юзаем уже сейчас :)
Лично мы юзаем для того, чтобы можно было на рабочем сервере получить ту же схему БД что и у нас без лишних телодвижений.
О,спасибо за добрые новости,а то извините достало то жуткое расширение.
Konstantin Mirin, да, расширение мы, конечно, тоже посмотрели и взяли оттуда несколько идей, но выросли миграции не только из него. Сыграли свою роль миграций RoR и миграции ibatis. Так что в ядро войдёт совсем не тот вариант, что есть в виде расширения.
Если будут пожелания к функционалу, багфиксы или патчи — обязательно рассмотрим.
Кстати, сейчас синтаксис команд и внутренности активно меняются. Если что-то не нравится, лучше предлагать сейчас.
Хотелось бы видеть функионал добавления индексов, ну и хелперы типа timestamps в RoR. И еще хотелось бы перенести миграции в shell, так имхо удобнее.
Индексы вроде уже в SVN, timestamp тоже. В shell точно переносить не будем — это создаст проблемы для тех, кто хочет автоматизировать применение миграций.
индексы нашел в svn, а вот timestamp? просто указывать 'created_at'=>'timestamp'?
Да. Для MySQL список типов такой:
а как в конфиге указывать таблицу в которой хранится история миграций.
Вот тут настройка описана.
Блин почему в Yii очень часто нюансы или важные вещи упущены в документации и приходится лезть в код. Вот как например с $columnTypes.
Хотя извиняюсь, в разделе «Построитель запросов» это было написано.
А можно ли в самом теле миграции использовать какую-либо модель?
Артем, можно, но лучше так не делать, чтобы миграции жили своей жизнью и не зависили от кода. Если произойдут какие-то критичные изменения с моделью, миграция не сможет выполнится, а править уже существующую не тру.
ПС помоему у Сэма была статья на этот счет.