Открыть список
Как стать автором
Обновить

Комментарии 22

Великолепно! Не хватает только запуска миграций из командной строки, что было бы полезно при автоматизации деплоя
Сегодня-завтра планировал дописать 2-ю статью про интеграцию с приложением, правда там пример пока-что делал с обновлением из админки.
В принципе, могу накидать примерчик и с обновлением через CLI, если это интересно.
проснулся и думаю — а может карму себе убить

… и чего эти русские не придумают, лишь бы дороги не строить (руби учить)
К.О. ответил бы, что программист, работающий на php, выучив руби, не всегда смог бы отказаться от поддержки оставшихся на php проектов.
Из ответа К.О. получается, что CodeIgniter написан для рубистов, которые поддерживают старые проекты на PHP?
Нихрена не понимаю. За что _тут_ минус, почему без о ответа (и так все понятно?)

Люди — они такие люди ))))

P.S. Жаль Капитана Очевидность, его авторитет сейчас явно спаразитирован.
да и почему это вообще другие языки существуют, а не только руби :)
да и почему это вообще другие языки существуют, а не только php :)
Бложик на рельсах я напишу немногим медленнее бложика на симфони, а вот с его деплоем и администрированием в продакшене проблем будет больше. Можно, конечно, добавить, что надо еще баш выучить, научиться пакеты собирать и т. п., но мне это мало интересно. Прототип на рельсах, потом релиз на пхп :)
>> а вот с его деплоем и администрированием в продакшене проблем будет больше
Почему?

>> Можно, конечно, добавить, что надо еще баш выучить, научиться пакеты собирать и т. п.
учить баш, собирать «пакеты», для «бложика» зачем?

>> Прототип на рельсах, потом релиз на пхп :)
realy?
Я имею в виду, что настроить и администрировать сервер под рельсы сложнее, чем для пхп. Особенно, если хочется, чтобы не нарушалась идеология привычного дистрибутива, чтобы, например, gem'ы управлялись штатным менеджером, а не рубивским. Для пхп тоже заморочек хватает, чтобы пакеты из PEAR или PECL в, например, deb перевести, но и требуется это реже и как-то субъективно проще.

Реально, прототипировать на рельсах проще: и локально разрабатывать, и показать кому-нибудь, выгрузив на хероку, да и гемов много для типовых вещей. А когда общая концепция приложения сложилась, основные детали утверждены, то на пхп лично мне писать и поддерживать проще, да и выгоднее, чем разбираться как гемы кастомизировать. Никто не хочет, почему-то, чтоб я просто развил прототип за те же деньги, узнав сколько стоит хостинг на том же хероку или услуги админа для поддержки рельс, или другого разработчика для развития приложения. Хотят чтоб я вдску сам админил, а я такие риски брать на себя не хочу (хотя беру часто) даже с пхп, не говоря про рельсы — тут точно не возьму, некомпетентен.
А чем можно сделать diff изменений БД? Например, у меня есть база в продакшене (old), к которой можно подключиться по сети и на локалхосте, где я разрабатываю (new). Можно ли сделать автоматическую генерацию up() и down()? Должны же быть алгоритмы.

Вопрос не применительно к CI, хотелось бы услышать ответ от людей, кто активно юзает миграции в своих проектах. Потому что гугление показывает, что такого инструмента, похоже, не существует.
Ну, например в EF CodeFirst CodeMigrations вполне себе есть автогенерация миграций на основании разницы между моделью в коде и моделью в БД.
да, mysqldiff.org я нагуглил первым делом, но на первый взгляд для нормальной работы там было применять не просто напильник, а бензопилу.
Посмотрю остальные ссылки, спасибо.
Имхо, даунгрейд полная панацея, только бэкапом можно откатиться корректно, если в базе есть данные.
Ну бэкапы никто и не отменял. Хотя без вреда новым данным бэкап скорее всего не восстановишь.
Интересная вещь, спасибо.
А оно само генерит диффы получается при коммитах?
да. и потом еще можно файл миграции поправить ручками, если что не так (там, ренейм поля в таблице вместо добавления/удаления или сразу первоначальный попьюлейшн данных).
Как видите, функции являются лишь обертками для protected метода для получения версии базы данных и опять же protected свойства $_migration_version, и вполне наглядно демонстрируют применение инкапсуляции.

Паблик Морозов: Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия. Название данного анти-паттерна — это каламбур, основанный на созвучии ключевого слова public (паблик), часто означающего открытый доступ к методам и полям класса в объектно-ориентированных языках программирования, и имени пионера-героя Павлика Морозова, известного тем, что он выдал своего отца-кулака.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.