ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.
Отработала на половину, значит делаем полный rollback и сообщаем о эксепшене. Соответственно ничего и не мигрируем до момента пока не исправим.
Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.
У меня как раз тот случай когда надо. Сервисы содержат методы со сложными выборками. Переписывать эти выборки или дублировать код ради этих целей — как-то не очень.
Возможно такие, что я неправильно их готовлю… Не особо в этом разбирался, миграции достались в наследство вместе с проектом. Попросту говоря, сейчас, это простой phar который всем управляет… Но что мне не нравится, так это то что достукаться до модулей приложения я не могу. Использовать такой же сахар, как скажем, в phinx тоже нет… Да и постоянные проблемы вылазят во время этих же миграций… То оно примененную миграцию в свою же таблицу записать не может, то ещё что-то…
Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.
Кажется, Вы тот кто понял мой вопрос. Огромное спасибо!
Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.
Есть команда, которая может удалять/добавлять поля/индексы итп. Всё это под контролем версий понятное дело. Разработчики всегда в курсе что твориться со структурой базы во время разработки, посредством конечно-же до боли знакомым всем — миграциям.
Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.
Но ведь просто сломать проект к чертям нельзя. Можно, конечно, чуть поломать, но ты ведь знаешь что сломал и где, и если оно до этого работало — то также знаешь как быстро починить. Что мешает зафиксать то что сломал вчера и преступить к просмотру котиков? Не понимаю.
Даже не в этом дело… Там была вообще смесь двух версий… Это привычка версии смешивать такая? :)
P.S Еще совет: Не засоряйте файл ненужными комментариями, например такими:
// Constructor
// Get root dir
// Get extension in lowercase
Там итак понятно что делают функции. Эти комментарии — мусор. А если уж и комментируете функции, то комментируйте их через block comments. Прокомментируйте что принимает, что возвращает итп.
Мне не надо это объяснять. Я разбираюсь что и где появилось и что и как объявляется. Дело привычки, или устаревший хлам? Весомый аргумент в том, что стабильная версия php 5.5, и пора ее использовать. А не писать в стиле php4, да и классы так называть еще…
Там автор еще переменные инициализирует через var и вместо __construct() у него там название класса :)
Не в обиду конечно, но возникает только один вопрос… Зачем?!
… а я то правда надеялся что php4 не увижу больше…
Разве? Я вызвал метод всего два разы. Один для всех javascript файлов и один для всех css файлов. Все это заняло одну строчку. А не 4. На каждый файл — вызов метода.
В этом, как мне кажется, и заключается суть asset managera. Что бы умно управлять ассетами, жать что надо и когда надо. Если в проекте очень много файлов которые старые, или вообще не используются, а выискивать их трудно — это проблема. Возможно ли реализовать такую фичу, скажем как u уникальный id? подключаешь файлики — вторым параметром тыкаешь версию, или какое-то id.
$bender->enqueue("assets/js/*", REVISION_ID);
А потом дописать несколько методов, скажем, detachRevision(), removeRevision etc. Пусть это и говнокод, но я считаю что удобно было бы пользоваться такой системой. Все-равно ненужные файлы лучше удалять вообще, ИМХО.
Согласен. С точки зрения «глобальности» — все верно. Это будет красиво, но не производительно. Но автор же делаете очередь с каких-то файлов, верно? Я просто за то что бы вызвать метод 1 раз, а не 10.
Отработала на половину, значит делаем полный rollback и сообщаем о эксепшене. Соответственно ничего и не мигрируем до момента пока не исправим.
У меня как раз тот случай когда надо. Сервисы содержат методы со сложными выборками. Переписывать эти выборки или дублировать код ради этих целей — как-то не очень.
Спасибо за наводку на ContainerAwareMigration. Обязательно посмотрю что это за зверь.
А ORM и нет :) Всё что от доктрины — миграции. По-этому phinx тут как раз кстати.
Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.
Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.
Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.
Очень актуальная тема, продолжайте переводить!
P.S Еще совет: Не засоряйте файл ненужными комментариями, например такими:
// Constructor
// Get root dir
// Get extension in lowercase
Там итак понятно что делают функции. Эти комментарии — мусор. А если уж и комментируете функции, то комментируйте их через block comments. Прокомментируйте что принимает, что возвращает итп.
Не в обиду конечно, но возникает только один вопрос… Зачем?!
… а я то правда надеялся что php4 не увижу больше…
А потом дописать несколько методов, скажем, detachRevision(), removeRevision etc. Пусть это и говнокод, но я считаю что удобно было бы пользоваться такой системой. Все-равно ненужные файлы лучше удалять вообще, ИМХО.
Чем он отличается от других? В Symfony, есть очень крутая штука, я просто оставлю ссылку:
symfony.com/doc/master/cookbook/assetic/asset_management.html
Это нынче не круто. Куда лучше было-бы что-то в этом роде
$bender->enqueue("assets/css/*")->enqueue("assets/js/*");