Используем миграции Yii2 для работы с несколькими базами данных

[DenisOgr]

А зачем ради одно строки — писать контроллеры, темплейты? У нас в проекте несколько БД. В нужных миграциях просто переопределям нужное проперти указывающее коннект к БД. Все!

[antonshell]

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

Хотелось чтобы в каждой базе была своя таблица migrate. Хотелось, чтобы у каждой БД было свое состояние. Хотелось, чтобы миграции для каждой базы данных хранились отдельно.

Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1. Их откатывать не нужно. Или нужно обновить только db1, а db2 не обновлять.

А зачем ради одно строки — писать контроллеры, темплейты

Ну, особо много кода писать не пришлось. Конечно, дублирование есть. Шаблоны копировать ради одной строчки наверное не стоило. Но это самое простое решение. И не создает особых проблем.

[DenisOgr]

хм… а зачем откатывать последние две миграции от одной БД?
а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…

Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1

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

и есть большая вероятность случайно накатить миграцию не на ту базу.

в процессе разработки вы увидели что накатиоли миграцию не в ту БД. зашли поправили. явно до лайфа/по мержа-до ревью кода такая миграция не доживет.
за все время что я писал миграции — ни разу такого не было… да и а что если кто то удалить вообще базу данных/таблицу/записи из таблицы миграцией? у вас есть защита от этого?

[antonshell]

Мне кажется, все зависит от проекта. И от того, кому как удобнее. Это 2 разных подхода. Я лишь предложил свое решение.

а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…

Одна БД — атомарное хранилище. А если 2 и более, все вместе это будет атомарное хранилище? В любом случае? Если в проекте несколько БД, то наверное на то есть свои причины.

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

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

Я думал только об удобстве использования. Мне удобнее, когда миграции для каждой бд лежат в своей папке. И если я обновляю db1, то я точно знаю, что обновляю именно db1.

Специально погуглил и нашел несколько примеров, не связанных с yii, где миграции все-таки разделены:

1. Здесь у человека несколько БД и для каждой своя таблица
   http://samokhvalov.info/blog/all/phinx-multiple-databases/
   
   
2. Фактически feature request на подобный функционал. Есть несколько рецептов, как это сделать. И в некоторых предлагается отдельно управлять каждой базой данных
   https://github.com/robmorgan/phinx/issues/180

Еще 2 примера, правда для Ruby. Я не работал с Ruby, но, если я правильно понял, здесь также предлагают разделение.

http://techvomit.net/multiple-dbs-with-active-record-sans-rails/

http://geekhmer.github.io/blog/2015/02/07/ruby-on-rails-connect-to-multiple-databases-and-migrations/

[pewpew]

Миграции, они ведь не только для БД. Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов. Поэтому логично использовать общую таблицу migrate и общее состояние.

[antonshell]

Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов.

Интересно, не встречал такого. Но не совсем понятно, как это влияет на общее состояние

Наверное это зависит от проекта. Если 2 базы данных действительно сильно связаны, то лучше все миграции вместе хранить и накатывать. Разумеется, я сначала рассматривал этот вариант. Но в итоге я решил, что управлять БД по отдельности будет удобнее.

Мне кажется, тут вопрос действительно больше в удобстве.

[antonshell]

del

[zvirusz]

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

[antonshell]

Да, наверное так и надо было сделать. Обновил статью, Спасибо.
Не знаю, можно/нужно ли шаблоны в конфиг вынести. Вынес только контроллеры.
Изначально хотел в модуль все это вынести, но почему-то стало лень…

[zvirusz]

В переопределении шаблонов нет смысла — миграции по-умолчанию используют ту же базу, что и контроллер.