Yii AR и migration diff

[Gas]

а просто делали сравнение при сборке пакета для деплоя

а можешь рассказать подробнее?
вот case: в базе появилась новая колонка, код её использует, если её в базе нет - он валится.
до продакшена понятно такое не дойдёт, но если у себя вечером апдетишься и хочешь что-то быстро сделать, а тут тебе wtf и нифига не работает, закомитивший боец уже пиво пьёт.

то-есть я себе представляю тогда комит через промежуточный скрипт, который сначала вызовет dbdiff какой-то и предупредит об изменениях базы, чтоб человек не забыл, а уже потом запустить svn commit / git push

 

[MiksIr]

Девелоперы работают с одной базой. Плюс есть эталонная. Когда идет деплой, т.е. выкатывание кода в продакшн, кроме всяких тестов и миграций написанных самими разработчиками еще делается сравнение схем базы, если они разные - генерится в скрипт миграции дополнительные инструкции. Потом это все уходит в продакшн, там выполняются все эти скрипты миграций и запускается код. Более сложные изменения, когда нужно загонять данные, пишутся руками, конечно. Но на практике на самом деле это встречалось не часто. А всякие простые типа добавил колонку или индекс - это вполне решает.

 

[keltanas]

MiksIr
А откуда берется эталонная база? Кто ее создает? Это же, как я понимаю, база со всеми миграциями, которые делали разработчики, и даже с теми, которые разработчики забыли. Тогда откуда известно, что там у разработчиков должно было получится?
Предполагается, что разработчик самостоятельно решает задачу, и ему не предписано добавить определенные поля. Поля добавляются в процессе решения задачи.

 

[Gas]

Сравнение идёт с девелоперской базой (только в ней же изменения) и деплой привязан к dev-серверу?

если они разные - генерится в скрипт миграции дополнительные инструкции

круто, а я бы по простому сравнение делал первым шагом и обрывал деплой с сообщеним, но у вас всё работает, молодцы.

 

[MiksIr]

Когда мы создаем пакет для деплоя, мы применяем все миграции на эталонную базу. Заодно проверяем, что diff ничего не накосячил, что ручные миграции написаны без косяков и т.п.
Разработчик написал код, добавил в свою базу колонку. Ночью пошел деплой, сравнили схему базы разработчика и эталонной, сгенерили альтеры, применили их на эталонную, отправили пакет в продакшн,применили там.

 

[MiksIr]

Да в общем что-то подобное, полагаю, многие деплой системы умеют делать сами. У нас был проект росший из небольшого, по-этому вся сборка по сути была записана в Makefile

 

[keltanas]

MiksIr
А если разработчик сидит где-нибудь в Китае, а эталонная база в США? И вот тому серверу, который занимается сборкой, ничего не известно, о том, как получить доступ к базе разработчика?
Или более прозаичный вариант, когда разработчик забирает из VCS обновление кода. И в то же время делает свою задачу. Откуда он получит изменения, которые должны произойти в его, тоже измененной базе?

ИМХО, вариант, когда в моделе прописана схема и она сама занимается подгоном базы под модель удобна, конечно, но только когда у нас небольшой проектик, который мы по ftp заливаем на наш продакшн изредка. В случае крыпных проектов с налаженным деплоем автоматическая миграция даже вредна из-за возможных пропущенных ошибок.

Имеется ввиду, что ты сравнивая схему модели и БД генеришь файл миграции. Если надо, правишь его ручками (мало ли тип полей накосячен, или еще что), а потом накатываешь эту миграцию на базу, разрабатываешь код, тестируешь, что все OK, а потом отправляешь код на сервер. Пример рабочего процесса одной AR библиотеки.

 

[MiksIr]

Я не занимаюсь сферическими конями. Я решаю исключительно те задачи, которые нужно. У меня конкретно - у всех разработчиков база одна.

> Имеется ввиду, что ты сравнивая схему модели и БД генеришь файл миграции.
Ну так пожалуйста - держи в vcs дамп схемы базы. Когда нужно добавить что-то - редактируй его, сравнивай банальным mysqldiff с базой, напиши скриптик из пары строк, который будет это загонять в шаблон файла миграции, редактируй, исполняй, проверяй.
Почти тот же самый процесс, только совершенно не привязанный к ORM.

 

[MiksIr]

Или наоборот, редактируем базу, потом перед комитом делаем диф с файликом с дампом, помещаем альтеры в миграцию, дампим базу - вуаля. Можно все это на vcs хуки повесить.

Или еще веселее - просто дампим базу каждый раз, а при апдейте смотим историю файла с дампом, сравиваем, генерим альтеры.

Потом оформляем все это в проект на гитхабе, делаем пост на хабре, поднимаем карму, продаемся гуглу, отдыхаем на канарах.
А в случае с приведенной вами ссылке - на Канарах отдыхать будет кто-то другой.
Решайте.

 

[grigori]

опять этот [чудак] троллит на тему "Yii плохой в нем нет [название фичи], которая есть в Symfony", причем на беспроигрышную тему, заложенную архитектурой фреймворка, ведь генерация миграций просто противоречит ключевой идее - автогенерации моделей

да, в symfony взяли модель django: пишем модель, генерируем миграции, автоматически обновляем структуру базы.
в yii наоборот: делаем базу, генерим модели, правим модели ручками, когда надо поменять базу - ручками пишем миграции и правим модели
спор тупоконечников и остроконечников

за повторный троллинг и высасывание аргументов из пальца закрываю ветку