<![CDATA[Комментарии / Профиль antonshell]]> https://habr.com/ru/users/antonshell/comments/ ru editor@habr.com habr.com Sat, 02 May 2026 06:56:18 GMT https://habr.com/ru/ https://habrastorage.org/webt/ym/el/wk/ymelwk3zy1gawz4nkejl_-ammtc.png Хабр 03.12.2017 16:05:23 https://habr.com/ru/articles/343610/#comment_10549532 https://habr.com/ru/articles/343610/#comment_10549532 Sun, 03 Dec 2017 16:05:23 GMT 01.12.2017 14:51:53 https://habr.com/ru/articles/343610/#comment_10547832 https://habr.com/ru/articles/343610/#comment_10547832 Fri, 01 Dec 2017 14:51:53 GMT 01.12.2017 04:45:44 https://habr.com/ru/articles/343610/#comment_10546806 https://habr.com/ru/articles/343610/#comment_10546806 Fri, 01 Dec 2017 04:45:44 GMT 23.07.2016 10:10:06 https://habr.com/ru/companies/2gis/articles/306166/#comment_9713168 https://habr.com/ru/companies/2gis/articles/306166/#comment_9713168 Sat, 23 Jul 2016 10:10:06 GMT 22.03.2016 20:48:22 https://habr.com/ru/articles/279701/#comment_8815623 https://habr.com/ru/articles/279701/#comment_8815623 Не знаю, можно/нужно ли шаблоны в конфиг вынести. Вынес только контроллеры.
Изначально хотел в модуль все это вынести, но почему-то стало лень…

]]> Tue, 22 Mar 2016 20:48:22 GMT 21.03.2016 20:52:16 https://habr.com/ru/articles/279701/#comment_8813707 https://habr.com/ru/articles/279701/#comment_8813707

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

Одна БД — атомарное хранилище. А если 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/
]]> Mon, 21 Mar 2016 20:52:16 GMT 21.03.2016 19:59:21 https://habr.com/ru/articles/279701/#comment_8813625 https://habr.com/ru/articles/279701/#comment_8813625 Ими можно решать такие задачи, как заполнение файлов в папке /upload/, например или переименовывание уже загруженных файлов.
Интересно, не встречал такого. Но не совсем понятно, как это влияет на общее состояние

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

Мне кажется, тут вопрос действительно больше в удобстве.
]]> Mon, 21 Mar 2016 19:59:21 GMT 20.03.2016 18:47:55 https://habr.com/ru/articles/279701/#comment_8812041 https://habr.com/ru/articles/279701/#comment_8812041 Как вариант, можно в каждой миграции указывать, к какой базе данных ее применять, или явно указывать бд в каждом запросе. Но это не очень удобно и есть большая вероятность случайно накатить миграцию не на ту базу. Кроме того, таблица миграций все равно будет только в основной базе.
Хотелось чтобы в каждой базе была своя таблица migrate. Хотелось, чтобы у каждой БД было свое состояние. Хотелось, чтобы миграции для каждой базы данных хранились отдельно.

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

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

Ну, особо много кода писать не пришлось. Конечно, дублирование есть. Шаблоны копировать ради одной строчки наверное не стоило. Но это самое простое решение. И не создает особых проблем.
]]> Sun, 20 Mar 2016 18:47:55 GMT 20.03.2016 18:46:49 https://habr.com/ru/articles/279701/#comment_8812037 https://habr.com/ru/articles/279701/#comment_8812037 ]]> Sun, 20 Mar 2016 18:46:49 GMT 15.02.2016 21:03:17 https://habr.com/ru/articles/277209/#comment_8773709 https://habr.com/ru/articles/277209/#comment_8773709 ]]> Mon, 15 Feb 2016 21:03:17 GMT 15.02.2016 20:57:23 https://habr.com/ru/articles/277209/#comment_8773703 https://habr.com/ru/articles/277209/#comment_8773703
Такого же типа скрипт для туннелирования — вот тут не загвоздка, не понимаю как это сделать, и можно ли вообще. Но, кажется, где-то мне что-то подобное попадалось, не могу сейчас найти.

Не знаю, можно ли подобным образом composer запустить… Для yii migrate и др. — просто веб версия, которая делает то же самое.

Наверняка что-то подобное уже сделано.
]]> Mon, 15 Feb 2016 20:57:23 GMT 15.02.2016 20:34:09 https://habr.com/ru/articles/277209/#comment_8773685 https://habr.com/ru/articles/277209/#comment_8773685
Обычно я подключаюсь к серверу по ssh, пробрасываю порт для mysq, подключаюсь через workbench или что-нибудь в этом роде. Клонирую проект в web директорию + ещё несколько дополнительных действий. Ну, или использую какое-нибудь деплой решение — capistrano, phing, самописный скрипт и т.д. Устанавливаю зависимости через composer, frontend зависимости через bower…
Потом для обновления достаточно выполнить команду git pull.

Но вдруг внезапно попадается виртуальный хостинг без ssh и имеющийся уже на нем проект, и понимаешь, что ничего из вышеперечисленного не работает. И добро пожаловать, filezilla, notepad++, phpmyadmin, редактирование по одному файлу.
И ещё php 5.2, не дай бог(с этим проблем меньше, чаще всего можно выбрать версию поновее).

И тут я понимаю, что некоторые до сих пор так и работают. Сам лично таких людей знаю. Ну, в общем, это конечно их дело, но даже непонятно, что им можно предложить. Фактически, сайт разрабатывается на production. Локально его запустить никто и никогда не пробовал. И даже с последней версией любимого фреймворка не особенно приятно в таких условиях работать. + Миграции работать не будут, т.к. их из консоли обычно запускают… Ftp медленный, файлов много мелких. При каждом изменении качать туда сюда весь проект — та ещё радость...

В общем не хватает инструментов, к которым привык и без которых впадаешь в уныние...
]]> Mon, 15 Feb 2016 20:34:09 GMT 15.02.2016 16:24:49 https://habr.com/ru/articles/277209/#comment_8773351 https://habr.com/ru/articles/277209/#comment_8773351 Mon, 15 Feb 2016 16:24:49 GMT 28.12.2015 20:20:10 https://habr.com/ru/companies/zfort/articles/274153/#comment_8719987 https://habr.com/ru/companies/zfort/articles/274153/#comment_8719987 Mon, 28 Dec 2015 20:20:10 GMT 19.12.2015 08:45:30 https://habr.com/ru/articles/273477/#comment_8695521 https://habr.com/ru/articles/273477/#comment_8695521 Sat, 19 Dec 2015 08:45:30 GMT 19.12.2015 06:12:52 https://habr.com/ru/articles/273477/#comment_8695451 https://habr.com/ru/articles/273477/#comment_8695451 Sat, 19 Dec 2015 06:12:52 GMT 12.11.2015 12:58:55 https://habr.com/ru/articles/270665/#comment_8652155 https://habr.com/ru/articles/270665/#comment_8652155 Thu, 12 Nov 2015 12:58:55 GMT 12.11.2015 12:58:41 https://habr.com/ru/articles/270665/#comment_8652151 https://habr.com/ru/articles/270665/#comment_8652151 Thu, 12 Nov 2015 12:58:41 GMT 20.10.2015 06:43:21 https://habr.com/ru/articles/269125/#comment_8620201 https://habr.com/ru/articles/269125/#comment_8620201 Tue, 20 Oct 2015 06:43:21 GMT 19.10.2015 23:34:29 https://habr.com/ru/articles/269125/#comment_8619991 https://habr.com/ru/articles/269125/#comment_8619991 Mon, 19 Oct 2015 23:34:29 GMT