Да, наверное так и надо было сделать. Обновил статью, Спасибо.
Не знаю, можно/нужно ли шаблоны в конфиг вынести. Вынес только контроллеры.
Изначально хотел в модуль все это вынести, но почему-то стало лень…
Мне кажется, все зависит от проекта. И от того, кому как удобнее. Это 2 разных подхода. Я лишь предложил свое решение.
а что если смотреть на БД как на атомарное хранилище, и не нужно его разделять…
Одна БД — атомарное хранилище. А если 2 и более, все вместе это будет атомарное хранилище? В любом случае? Если в проекте несколько БД, то наверное на то есть свои причины.
приведите пример такой задачи/проблемы. ну например, на лайфе нужно откатить последние миграции (которые удаляют таблицу с пользователями) (конец сарказма). серьезно, можно пример?
Зачем сарказм? Это и был пример(кажется, недостаточно удачный). Естественно, мне едва ли придется так делать. Вообще не так уж часто приходится откатывать миграции.
Я думал только об удобстве использования. Мне удобнее, когда миграции для каждой бд лежат в своей папке. И если я обновляю db1, то я точно знаю, что обновляю именно db1.
Специально погуглил и нашел несколько примеров, не связанных с yii, где миграции все-таки разделены:
Фактически feature request на подобный функционал. Есть несколько рецептов, как это сделать. И в некоторых предлагается отдельно управлять каждой базой данных https://github.com/robmorgan/phinx/issues/180
Еще 2 примера, правда для Ruby. Я не работал с Ruby, но, если я правильно понял, здесь также предлагают разделение.
Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов.
Интересно, не встречал такого. Но не совсем понятно, как это влияет на общее состояние
Наверное это зависит от проекта. Если 2 базы данных действительно сильно связаны, то лучше все миграции вместе хранить и накатывать. Разумеется, я сначала рассматривал этот вариант. Но в итоге я решил, что управлять БД по отдельности будет удобнее.
Мне кажется, тут вопрос действительно больше в удобстве.
Как вариант, можно в каждой миграции указывать, к какой базе данных ее применять, или явно указывать бд в каждом запросе. Но это не очень удобно и есть большая вероятность случайно накатить миграцию не на ту базу. Кроме того, таблица миграций все равно будет только в основной базе.
Хотелось чтобы в каждой базе была своя таблица migrate. Хотелось, чтобы у каждой БД было свое состояние. Хотелось, чтобы миграции для каждой базы данных хранились отдельно.
Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1. Их откатывать не нужно. Или нужно обновить только db1, а db2 не обновлять.
А зачем ради одно строки — писать контроллеры, темплейты
Ну, особо много кода писать не пришлось. Конечно, дублирование есть. Шаблоны копировать ради одной строчки наверное не стоило. Но это самое простое решение. И не создает особых проблем.
Правда, не уверен, что это вообще пригодится кому-то. Все-таки проще VPS купить, это уж точно. Да и я не то, чтобы очень часто в такие ситуации попадаю...
По идее ведь это должно быть даже не очень сложно сделать. Пишется скрипт на PHP, который запускается из браузера, скачивает удаленный репозиторий во временную папку, потом пробегает по проекту, смотрит изменения и обновляет файлы. Например. Может немного по-другому работать.
Такого же типа скрипт для туннелирования — вот тут не загвоздка, не понимаю как это сделать, и можно ли вообще. Но, кажется, где-то мне что-то подобное попадалось, не могу сейчас найти.
Не знаю, можно ли подобным образом composer запустить… Для yii migrate и др. — просто веб версия, которая делает то же самое.
Спасибо. Ну, да это понятно, что если просто скопироватьвесь проект, то будет все прекрасно работать. Это не к yii вопрос, а по развертыванию в целом.
Обычно я подключаюсь к серверу по ssh, пробрасываю порт для mysq, подключаюсь через workbench или что-нибудь в этом роде. Клонирую проект в web директорию + ещё несколько дополнительных действий. Ну, или использую какое-нибудь деплой решение — capistrano, phing, самописный скрипт и т.д. Устанавливаю зависимости через composer, frontend зависимости через bower…
Потом для обновления достаточно выполнить команду git pull.
Но вдруг внезапно попадается виртуальный хостинг без ssh и имеющийся уже на нем проект, и понимаешь, что ничего из вышеперечисленного не работает. И добро пожаловать, filezilla, notepad++, phpmyadmin, редактирование по одному файлу.
И ещё php 5.2, не дай бог(с этим проблем меньше, чаще всего можно выбрать версию поновее).
И тут я понимаю, что некоторые до сих пор так и работают. Сам лично таких людей знаю. Ну, в общем, это конечно их дело, но даже непонятно, что им можно предложить. Фактически, сайт разрабатывается на production. Локально его запустить никто и никогда не пробовал. И даже с последней версией любимого фреймворка не особенно приятно в таких условиях работать. + Миграции работать не будут, т.к. их из консоли обычно запускают… Ftp медленный, файлов много мелких. При каждом изменении качать туда сюда весь проект — та ещё радость...
В общем не хватает инструментов, к которым привык и без которых впадаешь в уныние...
На некоторых виртуальных хостингах консоль вообще ни в каком виде не доступна, только ftp. И тогда не то, что composer, даже git непонятно, как использовать. Кто-нибудь пробовал на таком развернуться. Понятно, что это жесть, и лучше использовать vps, но все же…
Спасибо за статью. Еще можно было бы использовать RBAC + бизнес правила. Мне кажется, хорошо подходит для вашей задачи. В yii2 работает из коробки. С symphony я не работал, к сожалению, но навеняка есть бандл для работы с rbac
Не знаю, можно/нужно ли шаблоны в конфиг вынести. Вынес только контроллеры.
Изначально хотел в модуль все это вынести, но почему-то стало лень…
Одна БД — атомарное хранилище. А если 2 и более, все вместе это будет атомарное хранилище? В любом случае? Если в проекте несколько БД, то наверное на то есть свои причины.
Зачем сарказм? Это и был пример(кажется, недостаточно удачный). Естественно, мне едва ли придется так делать. Вообще не так уж часто приходится откатывать миграции.
Я думал только об удобстве использования. Мне удобнее, когда миграции для каждой бд лежат в своей папке. И если я обновляю db1, то я точно знаю, что обновляю именно db1.
Специально погуглил и нашел несколько примеров, не связанных с yii, где миграции все-таки разделены:
http://samokhvalov.info/blog/all/phinx-multiple-databases/
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/
Интересно, не встречал такого. Но не совсем понятно, как это влияет на общее состояние
Наверное это зависит от проекта. Если 2 базы данных действительно сильно связаны, то лучше все миграции вместе хранить и накатывать. Разумеется, я сначала рассматривал этот вариант. Но в итоге я решил, что управлять БД по отдельности будет удобнее.
Мне кажется, тут вопрос действительно больше в удобстве.
Хотелось чтобы в каждой базе была своя таблица migrate. Хотелось, чтобы у каждой БД было свое состояние. Хотелось, чтобы миграции для каждой базы данных хранились отдельно.
Например нужно откатить последние 2 миграции для db2, Но после них уже было создано несколько миграций к db1. Их откатывать не нужно. Или нужно обновить только db1, а db2 не обновлять.
Ну, особо много кода писать не пришлось. Конечно, дублирование есть. Шаблоны копировать ради одной строчки наверное не стоило. Но это самое простое решение. И не создает особых проблем.
Такого же типа скрипт для туннелирования — вот тут не загвоздка, не понимаю как это сделать, и можно ли вообще. Но, кажется, где-то мне что-то подобное попадалось, не могу сейчас найти.
Не знаю, можно ли подобным образом composer запустить… Для yii migrate и др. — просто веб версия, которая делает то же самое.
Наверняка что-то подобное уже сделано.
Обычно я подключаюсь к серверу по ssh, пробрасываю порт для mysq, подключаюсь через workbench или что-нибудь в этом роде. Клонирую проект в web директорию + ещё несколько дополнительных действий. Ну, или использую какое-нибудь деплой решение — capistrano, phing, самописный скрипт и т.д. Устанавливаю зависимости через composer, frontend зависимости через bower…
Потом для обновления достаточно выполнить команду git pull.
Но вдруг внезапно попадается виртуальный хостинг без ssh и имеющийся уже на нем проект, и понимаешь, что ничего из вышеперечисленного не работает. И добро пожаловать, filezilla, notepad++, phpmyadmin, редактирование по одному файлу.
И ещё php 5.2, не дай бог(с этим проблем меньше, чаще всего можно выбрать версию поновее).
И тут я понимаю, что некоторые до сих пор так и работают. Сам лично таких людей знаю. Ну, в общем, это конечно их дело, но даже непонятно, что им можно предложить. Фактически, сайт разрабатывается на production. Локально его запустить никто и никогда не пробовал. И даже с последней версией любимого фреймворка не особенно приятно в таких условиях работать. + Миграции работать не будут, т.к. их из консоли обычно запускают… Ftp медленный, файлов много мелких. При каждом изменении качать туда сюда весь проект — та ещё радость...
В общем не хватает инструментов, к которым привык и без которых впадаешь в уныние...