Ну с RoR я действительно почти не знаком. Однако миграции на RoR я не стал использовать по 2м причинам:
1. Дополнительная зависимость — я работаю с PHP.
2. Не смог запустить. В Debian unstable, что стоит на моем лаптопе, никак не хотело устанавливаться. Странные зависимости в gem-ах. Виноваты в этом то ли мэйнтэйнеры пакетов Debian то ли мои кривые руки. Буквально две три недели назад я еще раз захотел пощупать rails — все завелось, однако сам Ruby пришлось собирать в ~/local и gem-ы туда же.
Пы. Сы. Спасибо за информацию о миграциях в рельсах.
Нэнэнэ. Если у вас php, то не надо заморачиватся. А в дебиане наверно надо так: apt-get install ruby, а потом из консольки gem install rails. Гемы из пакетов ставить _не надо_
там используется __DIR__, константа, которая была введена в 5.3
Для удаления тестовой базы используется register_shutdown_function, принимающая в параметр замкнутую функцию (closures)
Ну если это все зависимости, то легко даунгрейдить до 5.2. Сделайте хотя бы опцией.
А механизм миграций — это что-то общее для всех этих инструментов? Фактически хранятся диффы текущей версии с какой-то первой и накладываются при необходимости? При этом возможно указание логики для преобразования уже существующих данных?
Даунгредить до 5.2? Как вы себе представляете даунгредить замыкание? Мне важно, чтобы оно отрабатывало, даже если скрипт упадет — иначе мы получим кучу мусора в виде неудаленных бд с именами test234928349.
When using CLI the shutdown function doesn't get called if the process gets a SIGINT or SIGTERM. only the natural exit of PHP calls the shutdown function
>>Фактически хранятся диффы текущей версии с какой-то первой и накладываются при необходимости?
Верно!
>>При этом возможно указание логики для преобразования уже существующих данных?
Для этого нужно внести изменения в файл миграции. migration[0-9]+\.php
Инструментик хорош! Спасибо! Однако есть два но:
1. Java в зависимостях (знаю, что установка на любой системе == 5 мин.)
2. Нужно писать xml-код — не удовлетворяет первому требованию.
Сказать по чести, лично для себя я еще не нашел инструмента который бы подходил мне на 100%. Liquibase пока что приближается к идиалу, для реального мира Почему для реального? Может и ошибаюсь, но в большом приложение, пытаться автоматически отслеживать изменения БД — очень не благодарное дело. Триггеры, индексы, типы данных, чарсеты, движки БД — все это надо отслеживать.
Имхо самый реалистичный вариант — максимально облегчать себе жизнь в плане создания alter скриптов в полу ручном режиме.
К тому же у автоматизации есть еще один минус — одно дело менять структуру на базе в пару мегов. Другое — на 10 и ГБ и больше базе под нагрузкой — тут уже безопасней руками и очень, очень аккуратно :)
Но желаю вам удачи — больше инструментов разных и нужных.
Не могли бы Вы сказать причину такого витиеватого подхода в коде функции автозагрузки классов «mmpAutoload»? PHP ведь сам пробегается по путям, перечисленным в include_path при поиске необходимого файла, а Вы это делаете вручную.
И еще, для тех, кто портирует код под PHP 5.2: в функции __autoload до версии 5.3 нельзя было бросать исключения ( php.net/manual/en/language.oop5.autoload.php ). Здесь же автор использует spl_autoload_register, по ней ничего в документации не нашел, но было бы неплохо проверить, работает ли.
По теме топика: также использую самописный простой php-скрипт накатов ALTER-скриптов в зависимости от версии БД, которая также хранится в отдельной таблице. Ну еще он умеет развернуть начальный дамп из скрипта. ALTER-скрипты получаются ручками или копированием из сред управления БД типа EMS MySQL Manager.
В принципе, такого полуавтоматического «деплоймента» пока хватает и подобный инструмент действительно уменьшает рутину.
Нда, судя по всему, если в автолоадере необходимо кидать исключение, то без ручного поиска по путям из include_path не обойтись, потому что file_exists принимает абсолютный путь к файлу.
Не, spl_autoload_register -то работает, я имел в виду можно ли в функции, зарегистрированной через spl_autoload_register бросать исключение в PHP младше 5.3. По этой теме в доке сказано только про __autoload, но ведь мы регистрируем свою кастомную функцию и на нее эти правила могут не распространяться.
Проверил. Не ловятся в PHP < 5.3 исключения, брошенные в функции автозагрузчике, будь то __autoload или кастомная — всегда Fatal Error.
от себя скажу, что выбор PHP в качестве языка для таких задач, на мой взгляд, неудачен. хотя ваш проект написан гладко, но априори — для всех будущих разработок — вы много мучаетесь с тем, что в языках высокого уровня есть «из коробки» (т.е. — в стандартной библиотеке). командная строка на PHP — мучение (особенно попробуйте в windows). мое мнение — Python априори лучше для таких задач. тем не менее, спасибо за вашу разработку! уверен, она много кому пригодится ;-)
ну если не кривить душой то с python в винде дела обстоят не намного лучше чем с php, универсальное решение наверное — это использование java приложение, но каждый для себя определяет наиболее для него удобный инструмент в данный момент времени и на данном проекте.
Вы все делаете правильно. Отметаете готовые решения и скручиваете свой единственно правильный велосипед. Совсем как в басне про русского программиста.
Однако, дела обстоят еще более прозаично.
Создание проектов, подразумевающих более менее развитую инфраструктуру, на коленке, с постоянно меняющейся базой (да еще изменяемой произвольным количеством разработчиков) не должно быть по определению. Даже если не можете/не хотите/не успеваете спроектировать структуру базы сейчас, то со временем вы всеравно придете к более цивилизованным методам, а ее изменения не будут принимать глобальных масштабов, выходящих из-под контроля.
Создание сайтов или сайтиков может вестись и на коленке, но кому понадобится велосипед, да еще и со списком того, чего он не умеет? Возникают неудобства между 2-3 разработчиками? Можно вести простой файл с изменениями структуры, отметками о выполнении каждым разработчиком и датой фиксации на проде.
Ну каким бы ни был проект, требования имеют свойство изменяться в течении срока разработки. Изменение требований может повлечь за собой как изменения в коде, так и изменения структуры данных. Сколько бы ни было разработчиков 2 или 555 базу под (svn|git|hg|cvs) не положить, а соответственно нужен инструмент, который бы делал передачу изменений с наименьшими человеческими трудозатратами. Существующие инструменты хороши, но у большинства один недостаток (для меня лично — недостаток) — при их использовании нельзя менять базу напрямую. Мне неудобно вносить по несколько раз изменения в файлы (yml,xml и т.д.) потом применять миграцию в тот момент, когда я эксперементирую со структурой, индексами и т.д.. Неудобно потому, что в этот момент меня интересует только база, и никуда, кроме консольного mysql я смотреть в такие моменты не хочу. Когда я поменял структуру 555 раз и решил, что такая меня устраивает — я могу успокоиться и наконец создать миграцию. Ни один инструмент не удовлетворял одновременно двум требованиям — быть написанным на PHP и генерить миграции по отличиям от старой структуры, потому и появился мой велосипед.
> никуда, кроме консольного mysql я смотреть в такие моменты не хочу.
Ну это все объясняет. На велосипед обычно садятся, когда не нравится ходит пешком. В любом случае, подтяните спицы, смажьте цепь, отрегулируйте седло. Пользователям должно быть удобно ездить. И разумеется, такие вещи как установка новых катафотов, брызговиков и наклеек тоже будет не лишней.
Удачи вам.
Версионирование структуры БД в MySQL: MySQL Migration with PHP