Comments 22
Великолепно! Не хватает только запуска миграций из командной строки, что было бы полезно при автоматизации деплоя
Сегодня-завтра планировал дописать 2-ю статью про интеграцию с приложением, правда там пример пока-что делал с обновлением из админки.
В принципе, могу накидать примерчик и с обновлением через CLI, если это интересно.
В принципе, могу накидать примерчик и с обновлением через CLI, если это интересно.
Во второй статье про это написал: habrahabr.ru/blogs/codeigniter/133395/
проснулся и думаю — а может карму себе убить
… и чего эти русские не придумают, лишь бы дороги не строить (руби учить)
… и чего эти русские не придумают, лишь бы дороги не строить (руби учить)
К.О. ответил бы, что программист, работающий на php, выучив руби, не всегда смог бы отказаться от поддержки оставшихся на php проектов.
да и почему это вообще другие языки существуют, а не только руби :)
Бложик на рельсах я напишу немногим медленнее бложика на симфони, а вот с его деплоем и администрированием в продакшене проблем будет больше. Можно, конечно, добавить, что надо еще баш выучить, научиться пакеты собирать и т. п., но мне это мало интересно. Прототип на рельсах, потом релиз на пхп :)
>> а вот с его деплоем и администрированием в продакшене проблем будет больше
Почему?
>> Можно, конечно, добавить, что надо еще баш выучить, научиться пакеты собирать и т. п.
учить баш, собирать «пакеты», для «бложика» зачем?
>> Прототип на рельсах, потом релиз на пхп :)
realy?
Почему?
>> Можно, конечно, добавить, что надо еще баш выучить, научиться пакеты собирать и т. п.
учить баш, собирать «пакеты», для «бложика» зачем?
>> Прототип на рельсах, потом релиз на пхп :)
realy?
Я имею в виду, что настроить и администрировать сервер под рельсы сложнее, чем для пхп. Особенно, если хочется, чтобы не нарушалась идеология привычного дистрибутива, чтобы, например, gem'ы управлялись штатным менеджером, а не рубивским. Для пхп тоже заморочек хватает, чтобы пакеты из PEAR или PECL в, например, deb перевести, но и требуется это реже и как-то субъективно проще.
Реально, прототипировать на рельсах проще: и локально разрабатывать, и показать кому-нибудь, выгрузив на хероку, да и гемов много для типовых вещей. А когда общая концепция приложения сложилась, основные детали утверждены, то на пхп лично мне писать и поддерживать проще, да и выгоднее, чем разбираться как гемы кастомизировать. Никто не хочет, почему-то, чтоб я просто развил прототип за те же деньги, узнав сколько стоит хостинг на том же хероку или услуги админа для поддержки рельс, или другого разработчика для развития приложения. Хотят чтоб я вдску сам админил, а я такие риски брать на себя не хочу (хотя беру часто) даже с пхп, не говоря про рельсы — тут точно не возьму, некомпетентен.
Реально, прототипировать на рельсах проще: и локально разрабатывать, и показать кому-нибудь, выгрузив на хероку, да и гемов много для типовых вещей. А когда общая концепция приложения сложилась, основные детали утверждены, то на пхп лично мне писать и поддерживать проще, да и выгоднее, чем разбираться как гемы кастомизировать. Никто не хочет, почему-то, чтоб я просто развил прототип за те же деньги, узнав сколько стоит хостинг на том же хероку или услуги админа для поддержки рельс, или другого разработчика для развития приложения. Хотят чтоб я вдску сам админил, а я такие риски брать на себя не хочу (хотя беру часто) даже с пхп, не говоря про рельсы — тут точно не возьму, некомпетентен.
А чем можно сделать diff изменений БД? Например, у меня есть база в продакшене (old), к которой можно подключиться по сети и на локалхосте, где я разрабатываю (new). Можно ли сделать автоматическую генерацию up() и down()? Должны же быть алгоритмы.
Вопрос не применительно к CI, хотелось бы услышать ответ от людей, кто активно юзает миграции в своих проектах. Потому что гугление показывает, что такого инструмента, похоже, не существует.
Вопрос не применительно к CI, хотелось бы услышать ответ от людей, кто активно юзает миграции в своих проектах. Потому что гугление показывает, что такого инструмента, похоже, не существует.
Ну, например в EF CodeFirst CodeMigrations вполне себе есть автогенерация миграций на основании разницы между моделью в коде и моделью в БД.
Я по работе искал немного, но так уж вышло, что быстрее было вручную в моем случае написать.
Тем неменее может вам эти ссылки помогут (правда там под mysql вроде всё): www.mysqldiff.org/ и stackoverflow.com/questions/218499/mysql-diff-tool.
Тем неменее может вам эти ссылки помогут (правда там под mysql вроде всё): www.mysqldiff.org/ и stackoverflow.com/questions/218499/mysql-diff-tool.
Имхо, даунгрейд полная панацея, только бэкапом можно откатиться корректно, если в базе есть данные.
посмотрите еще на code.google.com/p/mygrate/
Как видите, функции являются лишь обертками для protected метода для получения версии базы данных и опять же protected свойства $_migration_version, и вполне наглядно демонстрируют применение инкапсуляции.
Паблик Морозов: Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия. Название данного анти-паттерна — это каламбур, основанный на созвучии ключевого слова public (паблик), часто означающего открытый доступ к методам и полям класса в объектно-ориентированных языках программирования, и имени пионера-героя Павлика Морозова, известного тем, что он выдал своего отца-кулака.
Паблик Морозов: Класс-потомок, созданный в соответствии с этим антипаттерном, выдает по запросу все данные класса-предка, независимо от степени их сокрытия. Название данного анти-паттерна — это каламбур, основанный на созвучии ключевого слова public (паблик), часто означающего открытый доступ к методам и полям класса в объектно-ориентированных языках программирования, и имени пионера-героя Павлика Морозова, известного тем, что он выдал своего отца-кулака.
Sign up to leave a comment.
Миграции баз данных — обзор библиотеки и ее использование