Comments 10
А зачем ради одно строки — писать контроллеры, темплейты? У нас в проекте несколько БД. В нужных миграциях просто переопределям нужное проперти указывающее коннект к БД. Все!
Как вариант, можно в каждой миграции указывать, к какой базе данных ее применять, или явно указывать бд в каждом запросе. Но это не очень удобно и есть большая вероятность случайно накатить миграцию не на ту базу. Кроме того, таблица миграций все равно будет только в основной базе.
Хотелось чтобы в каждой базе была своя таблица migrate. Хотелось, чтобы у каждой БД было свое состояние. Хотелось, чтобы миграции для каждой базы данных хранились отдельно.
Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1. Их откатывать не нужно. Или нужно обновить только db1, а db2 не обновлять.
А зачем ради одно строки — писать контроллеры, темплейты
Ну, особо много кода писать не пришлось. Конечно, дублирование есть. Шаблоны копировать ради одной строчки наверное не стоило. Но это самое простое решение. И не создает особых проблем.
хм… а зачем откатывать последние две миграции от одной БД?
а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…
приведите пример такой задачи/проблемы. ну например, на лайфе нужно откатить последние миграции (которые удаляют таблицу с пользователями) (конец сарказма). серьезно, можно пример?
за все время что я писал миграции — ни разу такого не было… да и а что если кто то удалить вообще базу данных/таблицу/записи из таблицы миграцией? у вас есть защита от этого?
а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…
Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1
приведите пример такой задачи/проблемы. ну например, на лайфе нужно откатить последние миграции (которые удаляют таблицу с пользователями) (конец сарказма). серьезно, можно пример?
и есть большая вероятность случайно накатить миграцию не на ту базу.в процессе разработки вы увидели что накатиоли миграцию не в ту БД. зашли поправили. явно до лайфа/по мержа-до ревью кода такая миграция не доживет.
за все время что я писал миграции — ни разу такого не было… да и а что если кто то удалить вообще базу данных/таблицу/записи из таблицы миграцией? у вас есть защита от этого?
Мне кажется, все зависит от проекта. И от того, кому как удобнее. Это 2 разных подхода. Я лишь предложил свое решение.
Одна БД — атомарное хранилище. А если 2 и более, все вместе это будет атомарное хранилище? В любом случае? Если в проекте несколько БД, то наверное на то есть свои причины.
Зачем сарказм? Это и был пример(кажется, недостаточно удачный). Естественно, мне едва ли придется так делать. Вообще не так уж часто приходится откатывать миграции.
Я думал только об удобстве использования. Мне удобнее, когда миграции для каждой бд лежат в своей папке. И если я обновляю db1, то я точно знаю, что обновляю именно db1.
Специально погуглил и нашел несколько примеров, не связанных с yii, где миграции все-таки разделены:
Еще 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/
а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…
Одна БД — атомарное хранилище. А если 2 и более, все вместе это будет атомарное хранилище? В любом случае? Если в проекте несколько БД, то наверное на то есть свои причины.
приведите пример такой задачи/проблемы. ну например, на лайфе нужно откатить последние миграции (которые удаляют таблицу с пользователями) (конец сарказма). серьезно, можно пример?
Зачем сарказм? Это и был пример(кажется, недостаточно удачный). Естественно, мне едва ли придется так делать. Вообще не так уж часто приходится откатывать миграции.
Я думал только об удобстве использования. Мне удобнее, когда миграции для каждой бд лежат в своей папке. И если я обновляю db1, то я точно знаю, что обновляю именно db1.
Специально погуглил и нашел несколько примеров, не связанных с yii, где миграции все-таки разделены:
- Здесь у человека несколько БД и для каждой своя таблица
http://samokhvalov.info/blog/all/phinx-multiple-databases/
- Фактически 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/
Миграции, они ведь не только для БД. Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов. Поэтому логично использовать общую таблицу migrate и общее состояние.
Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов.
Интересно, не встречал такого. Но не совсем понятно, как это влияет на общее состояние
Наверное это зависит от проекта. Если 2 базы данных действительно сильно связаны, то лучше все миграции вместе хранить и накатывать. Разумеется, я сначала рассматривал этот вариант. Но в итоге я решил, что управлять БД по отдельности будет удобнее.
Мне кажется, тут вопрос действительно больше в удобстве.
del
Почему бы просто в controllerMap не переопределять нужные свойства? Без каких-либо копирований и создания лишних классов.
Sign up to leave a comment.
Используем миграции Yii2 для работы с несколькими базами данных