Comments 8
Надо поковырять, миграции — вещь в хозяйстве нужная
Может кого заинтересуют и наши миграции из ZFCore — code.google.com/p/zfcore/wiki/Core_Migration
Может кого заинтересуют и наши миграции из ZFCore — code.google.com/p/zfcore/wiki/Core_Migration
Да, впечатляет. Я бы посоветовал использовать .zfproject.xml для получения информации о проекте. Раздел
<applicationDirectory>
...
<configsDirectory>
<applicationConfigFile type="ini"/>
</configsDirectory>
...
</applicationDirectory>
Подскажите, как решать проблему с одинаковыми индексами миграции на разных ветках в 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/ и соответственно хранить статус наката для каждой директории. При апдейте и даунгрейде указывать с какой папкой работаем:
Получается, что-то типа бранчей внутри системы миграции.
А может есть способ лучше?
Переименовывать 21.b => 22 проблематично:
1. Придётся переименовывать все последующие миграции.
2. У одного из участников сбивается нумерация: он уже накатывал свою миграцию 21.b, но 22 ещё не накатывал. При накате 22-ой, он ещё раз выполняет свою миграцию, но другую миграцию 21.a он не накатит.
Есть ли удобный способ решения данной проблемы, для максимальной автоматизации без ручного труда?
Я пока придумал способ (но ещё не реализовал), что бы для каждого участника хранить набор миграций в отдельной поддиректории ./scripts/migrations/user2/ и соответственно хранить статус наката для каждой директории. При апдейте и даунгрейде указывать с какой папкой работаем:
update -v=22 -u=user2
Получается, что-то типа бранчей внутри системы миграции.
А может есть способ лучше?
В ROR миграции маркеруются таймстемпом. В специальной табличке хранятся таймстемпы всех миграций, которые были применены.
К примеру, есть файлы:
FromDeveloper1/22-someAction.php
FromDeveloper2/22-someAction.php
Необходимо данные привести к виду:
проще говоря, вы собираете файлы миграций разных разработчиков по одним индексом, равным номеру миграции. Далее все очевидно.
FromDeveloper1/22-someAction.php
FromDeveloper2/22-someAction.php
Необходимо данные привести к виду:
$files=array(
'22' => array(
'FromDeveloper1/22-someAction.php',
'FromDeveloper2/22-someAction.php'
)
);
проще говоря, вы собираете файлы миграций разных разработчиков по одним индексом, равным номеру миграции. Далее все очевидно.
Sign up to leave a comment.
Миграция базы данных в Zend Framework: Akrabat_Db_Schema_Manager