Как правильно отразить в VCS применение миграции из vendor?

Question

[gto6120]

Добрый день. Мучает вопрос, как правильно запечатлеть в вечности тот факт, что применил миграцию, но не свою, которая у тебя в виде кода проекта лежит, а ту, что в папке vendor yii2 фрэймворка (папка эта под .gitignore как водится). Вижу вариант переносить миграцию из vendor внутрь проекта, но это как-то криво, ведь обновление стороннего расширения может затронуть и миграцию (обновилось расширение, требуются новые таблицы, к примеру), и тогда я должен буду вручную переносить изменения, возможно есть и еще проблемы, интуитивно чувствую, что это неправильно.

А еще есть такой момент, что применив миграцию из vendor:

php yii migrate --migrationPath=@yii/rbac/migrations/

Я обнаруживаю, что созданные таблицы не связаны с моей таблицей user внешним ключом.



Теперь мне это как-то нужно исправить, но я даже не знаю как: руками в БД лезть нельзя, миграция за пределами редактируемой части проекта...Выходит все же нужно ее перетянуть внутрь? Как решаете такие задачи?

Просьба не кидаться помидорами, я только накатил advanced-шаблон и на нем хочу увидеть в действии работу rbac и заодно поупражняться в работе с git.

Answer 1

[Максим Тимофеев]

На мой взгляд надо переписать контролер миграции (создать свой и подключить в конфиге)
Вот есть пример, для двух баз, но там есть пример конфига для кастомного контролера:
https://habrahabr.ru/post/279701/
Далее в экшене migrate можно добавить копирование файла в папку console/migrations например и иметь их в проекте не зависимо от изменений в vendor.

Comments

[gto6120]

Код из статьи ужасный((

[Максим Тимофеев]

gto6120: Я конкретно про конфиг в нем.

[gto6120]

а конфиг-то что, просто класс подмени и все

[gto6120]

Возможно, это решение, я попробую реализовать, но пока еще подожду ответов

[gto6120]

Должно быть простое решение, есть ведь миграции, ими пользуются люди как-то, наверняка уже эту проблему решали как-то

[Максим Тимофеев]

gto6120: То что я предложил (забыли про линк), это и есть простое решение.

[gto6120]

Скорее всего. // Что значит "забыли про линк", я не понял?

[Максим Тимофеев]

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

[gto6120]

Все, понял. Таким путем и пойду.

Answer 2

[Евгений Бухарев]

/**
 * Class m170113_172800_add_subscribe_table.
 */
class m170113_172800_add_subscribe_table extends \backend\modules\subscribe\migrations\m170113_150000_subscribe
{

}

Comments

[gto6120]

Что это значит?

[Евгений Бухарев]

gto6120: Создайте свою миграцию в папке проекта, и отнаследуйте её от миграции в вендоре, при этом ваш вопрос разрешится

[gto6120]

Ух тыы))) Прикольно, не знал. Но вот что будет если я отнаследуюсь от того что в /vendor, а другой разработчик обновив у себя расширение имеет другой базовый класс. Итог - рассинхронизация. Он напишет код опирающийся на его мигрцию (новую) из vendor и зальет его в реп, а я забрав его код к себе получу неработающее приложение.

[Максим Тимофеев]

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

[Евгений Бухарев]

gto6120: Максим Тимофеев: Здесь ситуация такая что в вендоре может что угодно произойти, поэтому данное решение наиболее подходящее чем копипастить миграцию к себе в проект из вендора, а если смущает рассинхронизация, nто можно повесить массу проверок на наличие самой таблицы, на наличие поля в таблице и т.д, до этого достаточно перепределить метод Up либо Down, написать проверки и вызвать либо не вызывать родительский метод

[gto6120]

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

[Максим Тимофеев]

evgenybuckharev: Все изменения учесть не получится. И логично иметь у себя именно ту миграцию, которую выполнил. К тому же все миграции будут в одном месте. Плюс если разработчик плагина не предусмотрел обратной миграции, ее можно ручками доделать. Я честно говоря удивлен, что в yii этого нет из коробки. Перенос миграции, которая выполнена в отдельную папку решает все проблемы и решает на 100%, в отличии от проверок.

[Евгений Бухарев]

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