PHP - схема базы данных: управление версиями, ветвление, миграция

Я пытаюсь найти (или найти) систему многократного использования для управления версиями схемы базы данных в проектах php.

Существует ряд проектов миграции в стиле Rails, доступных для php. http://code.google.com/p/mysql-php-migrations/ - хороший пример. Он использует временные метки для файлов миграции, что помогает в конфликтах между ветвями.

Общая проблема с такой системой: Когда ветка разработки A проверена, и вы хотите проверить ветку B вместо этого, B могут иметь новые файлы миграции. Это нормально, переход на более новый контент прямо.

Если ветвь A имеет более новые файлы миграции, вам нужно будет перейти вниз к ближайшему общему патчу. Если ветки А и В имеют существенно разные кодовые базы, вам, возможно, придется мигрировать еще дальше. Это может означать: Проверьте B, определите общий номер патча, проверьте A, перенесите вниз этот патч. Это должно быть сделано от A, так как фактические прикладные исправления недоступны в B. Затем выберете ветку B и перенесите на новый B-патч. Обратный процесс снова при переходе от B к A.

Предлагаемая система: При переносе вверх, вместо того, чтобы просто хранить версию патча, сериализуйте весь патч в базе данных для последующего использования, хотя мне, вероятно, понадобится только метод down(). При изменении веток сравнивайте патчи, которые были запущены для патчей, доступных в ветке назначения. Определите ближайший общий патч (или самое раннее различие, возможно) между таблицей db патчей запуска и патчами в ветке назначения по идентификатору или хешу. Также можно искать новые или отсутствующие патчи, которые были захоронены под несколькими общими патчами между двумя ветвями.

Автоматически объединять до ближайшего общего патча, используя методы db table stored down(), а затем объединить до последнего патча ветки.

Мой вопрос: Является ли эта система слишком сумасшедшей и/или чреватой последствиями для развития? Мой опыт работы с версией схемы базы данных ограничен автозагрузкой PHP, которая является системой up(), которая требует имена файлов с последовательными идентификаторами.

Обновление, спустя 2 года

Это старый пост, но я хотел упомянуть, что я вообще вообще отказался от миграции во время разработки, поскольку они излишне сложны и подвержены ошибкам.

Вместо этого я использую скрипты сборки для:

При изменении веток или получении обновлений от других разработчиков вы полностью загружаете базу данных одной командой, чтобы перейти в известное состояние.

Серверы производства по-прежнему нуждаются в патчах базы данных, но их все равно придется создавать вручную.

Ответы

Ответ 1

Ну, я не мог найти причин, чтобы не двигаться вперед.

Проект, например, находится здесь:

http://github.com/Billiam/MySQL-PHP-AutoMigrations

Требуется некоторая любовь (точные комментарии, модульное тестирование, фактическое тестирование ошибок), но, похоже, сейчас работает хорошо для меня.

Это вилка http://code.google.com/p/mysql-php-migrations/, чтобы включить вышеизложенные идеи и некоторые другие мелочи.

Миграция происходит из методов, сохраненных в базе данных на пути вверх, так что изменения файла (например, при переключении между ветвями) не влияют на миграцию вниз. Добавлено две функции:

волшебная функция "auto", которая обрабатывает переход до самой старой общей миграции, а затем до самой последней миграции в каталоге миграции.
"предлагать" функцию, которая показывает, что будет делать авто.

Тем не менее очень открытые возможности для слуха (или даже ожидаемые) из этого подхода.