Comments 51
«Doctrine — подход тот же что и в RoR» — ??? 0_о
Во всяком случае я так понял: Нужно изменить либо модель, либо schema.yml, потом только сгенерировать миграцию.
В RoR можно генерировать миграции вообще без моделей.
script/generate migration migration_name
script/generate migration migration_name
Все поняли не правильно, или недопоняли. Миграции в RoR — это файлы где специальным DSL-ем описывают изменение структуры БД. Модели тут не причем.
Ну с RoR я действительно почти не знаком. Однако миграции на RoR я не стал использовать по 2м причинам:
1. Дополнительная зависимость — я работаю с PHP.
2. Не смог запустить. В Debian unstable, что стоит на моем лаптопе, никак не хотело устанавливаться. Странные зависимости в gem-ах. Виноваты в этом то ли мэйнтэйнеры пакетов Debian то ли мои кривые руки. Буквально две три недели назад я еще раз захотел пощупать rails — все завелось, однако сам Ruby пришлось собирать в ~/local и gem-ы туда же.
Пы. Сы. Спасибо за информацию о миграциях в рельсах.
1. Дополнительная зависимость — я работаю с PHP.
2. Не смог запустить. В Debian unstable, что стоит на моем лаптопе, никак не хотело устанавливаться. Странные зависимости в gem-ах. Виноваты в этом то ли мэйнтэйнеры пакетов Debian то ли мои кривые руки. Буквально две три недели назад я еще раз захотел пощупать rails — все завелось, однако сам Ruby пришлось собирать в ~/local и gem-ы туда же.
Пы. Сы. Спасибо за информацию о миграциях в рельсах.
Обновил информацию по поводу Doctrine и RoR.
После поверхностного ознакомления не очень понял почему PHP >= 5.3
Слишком поверхностно ознакомился?
Слишком поверхностно ознакомился?
там используется __DIR__, константа, которая была введена в 5.3
Для удаления тестовой базы используется register_shutdown_function, принимающая в параметр замкнутую функцию (closures)
Для удаления тестовой базы используется register_shutdown_function, принимающая в параметр замкнутую функцию (closures)
Ну если это все зависимости, то легко даунгрейдить до 5.2. Сделайте хотя бы опцией.
А механизм миграций — это что-то общее для всех этих инструментов? Фактически хранятся диффы текущей версии с какой-то первой и накладываются при необходимости? При этом возможно указание логики для преобразования уже существующих данных?
ЗЫ: Ruby
А механизм миграций — это что-то общее для всех этих инструментов? Фактически хранятся диффы текущей версии с какой-то первой и накладываются при необходимости? При этом возможно указание логики для преобразования уже существующих данных?
ЗЫ: Ruby
Даунгредить до 5.2? Как вы себе представляете даунгредить замыкание? Мне важно, чтобы оно отрабатывало, даже если скрипт упадет — иначе мы получим кучу мусора в виде неудаленных бд с именами test234928349.
Вы знаете, register_shutdown_function существует с 4-го PHP.
Прекрасно знаю. Так же прекрасно знаю, что замыкания сущетвуют с 5.3.
Впрочем, если вы предложите стабильно-работающий патч — я готов включить его в код.
Впрочем, если вы предложите стабильно-работающий патч — я готов включить его в код.
__DIR__ === dirname(__FILE__)
register_shutdown_function(function() use($config,$tmpdb)
{
Helper::verbose(«database {$config['db']} droped»);
$tmpdb->query(«drop database `{$config['db']}`»);
})
;
register_shutdown_function(create_function(
'$config, $tmpdb',
'
Helper::verbose(«database {$config[\'db\']} droped»);
$tmpdb->query(«drop database `{$config[\'db\']}`»);
'
), $config, $tmpdb);
register_shutdown_function(function() use($config,$tmpdb)
{
Helper::verbose(«database {$config['db']} droped»);
$tmpdb->query(«drop database `{$config['db']}`»);
})
;
register_shutdown_function(create_function(
'$config, $tmpdb',
'
Helper::verbose(«database {$config[\'db\']} droped»);
$tmpdb->query(«drop database `{$config[\'db\']}`»);
'
), $config, $tmpdb);
>>Фактически хранятся диффы текущей версии с какой-то первой и накладываются при необходимости?
Верно!
>>При этом возможно указание логики для преобразования уже существующих данных?
Для этого нужно внести изменения в файл миграции. migration[0-9]+\.php
Верно!
>>При этом возможно указание логики для преобразования уже существующих данных?
Для этого нужно внести изменения в файл миграции. migration[0-9]+\.php
Обновил статью, добавив информацию о механизме работы миграций.
А вот это не прообовали? www.liquibase.org/ На жава, но не вижу с этим проблем. Устновка и настройка JVM будет явно быстрее чем самому писать.
Инструментик хорош! Спасибо! Однако есть два но:
1. Java в зависимостях (знаю, что установка на любой системе == 5 мин.)
2. Нужно писать xml-код — не удовлетворяет первому требованию.
1. Java в зависимостях (знаю, что установка на любой системе == 5 мин.)
2. Нужно писать xml-код — не удовлетворяет первому требованию.
Сказать по чести, лично для себя я еще не нашел инструмента который бы подходил мне на 100%. Liquibase пока что приближается к идиалу, для реального мира Почему для реального? Может и ошибаюсь, но в большом приложение, пытаться автоматически отслеживать изменения БД — очень не благодарное дело. Триггеры, индексы, типы данных, чарсеты, движки БД — все это надо отслеживать.
Имхо самый реалистичный вариант — максимально облегчать себе жизнь в плане создания alter скриптов в полу ручном режиме.
К тому же у автоматизации есть еще один минус — одно дело менять структуру на базе в пару мегов. Другое — на 10 и ГБ и больше базе под нагрузкой — тут уже безопасней руками и очень, очень аккуратно :)
Но желаю вам удачи — больше инструментов разных и нужных.
Имхо самый реалистичный вариант — максимально облегчать себе жизнь в плане создания alter скриптов в полу ручном режиме.
К тому же у автоматизации есть еще один минус — одно дело менять структуру на базе в пару мегов. Другое — на 10 и ГБ и больше базе под нагрузкой — тут уже безопасней руками и очень, очень аккуратно :)
Но желаю вам удачи — больше инструментов разных и нужных.
Для Питона + Django стоит упомянуть south. По модели данных проекта генерирует миграционные скрипты для разных БД.
Не могли бы Вы сказать причину такого витиеватого подхода в коде функции автозагрузки классов «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.
В принципе, такого полуавтоматического «деплоймента» пока хватает и подобный инструмент действительно уменьшает рутину.
И еще, для тех, кто портирует код под 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 принимает абсолютный путь к файлу.
ru.php.net/manual/en/function.spl-autoload-register.php — конечно работает
За исключение спасибо.
За исключение спасибо.
Не, spl_autoload_register -то работает, я имел в виду можно ли в функции, зарегистрированной через spl_autoload_register бросать исключение в PHP младше 5.3. По этой теме в доке сказано только про __autoload, но ведь мы регистрируем свою кастомную функцию и на нее эти правила могут не распространяться.
Проверил. Не ловятся в PHP < 5.3 исключения, брошенные в функции автозагрузчике, будь то __autoload или кастомная — всегда Fatal Error.
Проверил. Не ловятся в PHP < 5.3 исключения, брошенные в функции автозагрузчике, будь то __autoload или кастомная — всегда Fatal Error.
Мигратор для zf code.google.com/p/zfcore/wiki/Core_Migration
Думаю можно юзать отдельно.
Думаю можно юзать отдельно.
Не забудьте про dbdeploy.
Несколько баз одновременно поддерживало бы еще…
Да на разных серверах.
Оно конечно можно и пачку конфигов и пачку скриптов, но для ленивых…
:-)
Да на разных серверах.
Оно конечно можно и пачку конфигов и пачку скриптов, но для ленивых…
:-)
я — разработчик mygrate, спасибо за упоминание!
от себя скажу, что выбор PHP в качестве языка для таких задач, на мой взгляд, неудачен. хотя ваш проект написан гладко, но априори — для всех будущих разработок — вы много мучаетесь с тем, что в языках высокого уровня есть «из коробки» (т.е. — в стандартной библиотеке). командная строка на PHP — мучение (особенно попробуйте в windows). мое мнение — Python априори лучше для таких задач. тем не менее, спасибо за вашу разработку! уверен, она много кому пригодится ;-)
от себя скажу, что выбор PHP в качестве языка для таких задач, на мой взгляд, неудачен. хотя ваш проект написан гладко, но априори — для всех будущих разработок — вы много мучаетесь с тем, что в языках высокого уровня есть «из коробки» (т.е. — в стандартной библиотеке). командная строка на PHP — мучение (особенно попробуйте в windows). мое мнение — Python априори лучше для таких задач. тем не менее, спасибо за вашу разработку! уверен, она много кому пригодится ;-)
ну если не кривить душой то с python в винде дела обстоят не намного лучше чем с php, универсальное решение наверное — это использование java приложение, но каждый для себя определяет наиболее для него удобный инструмент в данный момент времени и на данном проекте.
Согласен насчет выбора языка, но при всех этих минусах для PHP проектов этот выбор все равно останется лучшим
Вы все делаете правильно. Отметаете готовые решения и скручиваете свой единственно правильный велосипед. Совсем как в басне про русского программиста.
Однако, дела обстоят еще более прозаично.
Создание проектов, подразумевающих более менее развитую инфраструктуру, на коленке, с постоянно меняющейся базой (да еще изменяемой произвольным количеством разработчиков) не должно быть по определению. Даже если не можете/не хотите/не успеваете спроектировать структуру базы сейчас, то со временем вы всеравно придете к более цивилизованным методам, а ее изменения не будут принимать глобальных масштабов, выходящих из-под контроля.
Создание сайтов или сайтиков может вестись и на коленке, но кому понадобится велосипед, да еще и со списком того, чего он не умеет? Возникают неудобства между 2-3 разработчиками? Можно вести простой файл с изменениями структуры, отметками о выполнении каждым разработчиком и датой фиксации на проде.
Однако, дела обстоят еще более прозаично.
Создание проектов, подразумевающих более менее развитую инфраструктуру, на коленке, с постоянно меняющейся базой (да еще изменяемой произвольным количеством разработчиков) не должно быть по определению. Даже если не можете/не хотите/не успеваете спроектировать структуру базы сейчас, то со временем вы всеравно придете к более цивилизованным методам, а ее изменения не будут принимать глобальных масштабов, выходящих из-под контроля.
Создание сайтов или сайтиков может вестись и на коленке, но кому понадобится велосипед, да еще и со списком того, чего он не умеет? Возникают неудобства между 2-3 разработчиками? Можно вести простой файл с изменениями структуры, отметками о выполнении каждым разработчиком и датой фиксации на проде.
Ну каким бы ни был проект, требования имеют свойство изменяться в течении срока разработки. Изменение требований может повлечь за собой как изменения в коде, так и изменения структуры данных. Сколько бы ни было разработчиков 2 или 555 базу под (svn|git|hg|cvs) не положить, а соответственно нужен инструмент, который бы делал передачу изменений с наименьшими человеческими трудозатратами. Существующие инструменты хороши, но у большинства один недостаток (для меня лично — недостаток) — при их использовании нельзя менять базу напрямую. Мне неудобно вносить по несколько раз изменения в файлы (yml,xml и т.д.) потом применять миграцию в тот момент, когда я эксперементирую со структурой, индексами и т.д.. Неудобно потому, что в этот момент меня интересует только база, и никуда, кроме консольного mysql я смотреть в такие моменты не хочу. Когда я поменял структуру 555 раз и решил, что такая меня устраивает — я могу успокоиться и наконец создать миграцию. Ни один инструмент не удовлетворял одновременно двум требованиям — быть написанным на PHP и генерить миграции по отличиям от старой структуры, потому и появился мой велосипед.
Буду очень рад, если он облегчит кому-то жизнь.
Буду очень рад, если он облегчит кому-то жизнь.
> никуда, кроме консольного mysql я смотреть в такие моменты не хочу.
Ну это все объясняет. На велосипед обычно садятся, когда не нравится ходит пешком. В любом случае, подтяните спицы, смажьте цепь, отрегулируйте седло. Пользователям должно быть удобно ездить. И разумеется, такие вещи как установка новых катафотов, брызговиков и наклеек тоже будет не лишней.
Удачи вам.
Ну это все объясняет. На велосипед обычно садятся, когда не нравится ходит пешком. В любом случае, подтяните спицы, смажьте цепь, отрегулируйте седло. Пользователям должно быть удобно ездить. И разумеется, такие вещи как установка новых катафотов, брызговиков и наклеек тоже будет не лишней.
Удачи вам.
UFO just landed and posted this here
Sign up to leave a comment.
Версионирование структуры БД в MySQL: MySQL Migration with PHP