Миграция базы данных в Zend Framework: Akrabat_Db_Schema_Manager

[@AntonShevchuk]

Надо поковырять, миграции — вещь в хозяйстве нужная

Может кого заинтересуют и наши миграции из ZFCore — code.google.com/p/zfcore/wiki/Core_Migration

[@3axap4eHko]

Да, впечатляет. Я бы посоветовал использовать .zfproject.xml для получения информации о проекте. Раздел

<applicationDirectory>
...
    <configsDirectory>
        <applicationConfigFile type="ini"/>
    </configsDirectory>
...
</applicationDirectory>

содержит исчерпывающую информацию и обязательные параметры при инстанцировании класса Core_Migration_Manager можно опустить, получив их из конфига директории приложения, при этом директория приложения по дефолту application, но изменяется, если я не ошибаюсь в атрибуте filesystemName.

[@resurection]

Подскажите, как решать проблему с одинаковыми индексами миграции на разных ветках в DCVS? Т.е. например, есть 20 файлов-миграций и два разработчика между которыми всё засинхронизированно. Оба начинают разрабатывать новый ф-ционал на разных ветках и каждый создаёт 21-ый файл миграции. После слияния получается две 21-ых миграции (21.a + 21.b) и ещё пачка миграций: 22, 23, 24,…
Переименовывать 21.b => 22 проблематично:
1. Придётся переименовывать все последующие миграции.
2. У одного из участников сбивается нумерация: он уже накатывал свою миграцию 21.b, но 22 ещё не накатывал. При накате 22-ой, он ещё раз выполняет свою миграцию, но другую миграцию 21.a он не накатит.

Есть ли удобный способ решения данной проблемы, для максимальной автоматизации без ручного труда?

Я пока придумал способ (но ещё не реализовал), что бы для каждого участника хранить набор миграций в отдельной поддиректории ./scripts/migrations/user2/ и соответственно хранить статус наката для каждой директории. При апдейте и даунгрейде указывать с какой папкой работаем:

update -v=22 -u=user2

Получается, что-то типа бранчей внутри системы миграции.
А может есть способ лучше?

[@dizer]

В ROR миграции маркеруются таймстемпом. В специальной табличке хранятся таймстемпы всех миграций, которые были применены.

[@resurection]

Ну всё!
Срочно переписываем все проекты с ZF на ROR! увольняем весь штат php-прогеров и пол года ищем новую команду рубистов!

[@dizer]

Было бы здорово. Но для начала можете просто повторить решения великого RoR.

[@resurection]

Да ну что вы! Переписывать RoR на php — это же костыль! Лучше уж тотальный рефакторинг.

Хотя ниже уже подсказали изящное решение на php. Рефакторинг и переписывание отменяются.

[@3axap4eHko]

К примеру, есть файлы:
FromDeveloper1/22-someAction.php
FromDeveloper2/22-someAction.php
Необходимо данные привести к виду:

$files=array(
    '22' => array(
        'FromDeveloper1/22-someAction.php',
        'FromDeveloper2/22-someAction.php'
    )
);

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