agagaheash ashaherya4wr, рекомендация посмотреть в сторону ORM дана исходя из вопроса. Видно, что человек новичок, и возможно не знает, что есть более удобные вещи, чем писать голые запросы из php. Будет использовать или нет - не важно, главное, что будет знать (если почитает)
HellWalk, хорошо) mysql с парой реплик вполне хорошо справляется, но не в одиночку. Неотъемлемая часть проекта - redis, который собирает в себя кучу мелочи, которая потом пишется одной транзакций в mysql. Почти весь поиск и фильтры лежат на ElasticSearch - работает в 1000 раз быстрее и разгружает mysql.
В целом, сейчас пишем версию проекта 2.0. Стек технологий будет тот же (разве что добавится ClickHouse), просто само приложение будет разбито на независимые кластеры, что позволит проще и легче масштабироваться горизонтально
xfg: я и реагирую, о чем написал выше уже не раз. У меня для этих целей есть sentry. Вопрос про то, для чего нужны коды. Добавил upd в вопрос.
Станислав Б: Да, если делать общий HttpException то там да, понятно. Так например в Yii юзается. Мне интересны еще другие примеры из реальной жизни. Я кроме HttpException ничего придумать не могу. Я не ищу способа по принципу "куда бы мне их воткнуть". Мне интересны best practices и use cases
Вопрос на самом деле один, и он выделен жирным: что писать в exception code когда я выбрасываю исключение?
Дальше я привожу возможные сценарии того, как можно использовать коды исключений. Это разные варианты, а не последовательность действий. У меня нет проблем с логированием исключений и поиском проблемных ситуаций. В sentry это все у меня разруливается прекрасно. Я не понимаю, для каких целей нужен код? Как его использовать и для чего?
Вот я и спрашиваю :) зачем? Зачем они нужны и кто что в них пишет?
Про то, как работать с логами я понимаю. Сам юзаю sentry и найти ту или иную ошибку не сложно. Но мои клиенты кстати как ни странно всегда пишут тикеты со словами "возникла ошибка XXX"
Ну и фабрика тоже вроде как не для этого. Она все равно не дает создать объект нужного класса через DI передав ему в конструктор параметр например полученный в GET запросе в контроллере
>где гарантии, что конструкторы у этих классов будет совпадать?
Так гарантий и нет. Если они не совпадают, то я считаю что приложение должно вылететь с ошибкой, и это будет правильно, т.к. это уже логическая ошибка. Это же вроде как L из SOLID
bears: именно свои параметры. Например в контроллере я хочу создать объект в конструктор которого мне нужно передать скажем какой-то параметр из GET. Но я не хочу создавать напрямую объект типа $obj = new Object($name). Вместо этого у меня есть ObjectInterface и несколько его реализаций, одну из которых я хочу указать в DI чтобы он по имени интерфейса создавал нужный объект, в конструктор которого передав параметр. Пример кода в вопросе наглядно иллюстрирует ситуацию
slo_nik: я сделал upd в основном вопросе. Понял, что сбивает людей с толку.
main-local.php и params-local.php имеются в виду те, что используются в production, и вопрос в том, как именно их (конфиги для production) лучше загружать на сервер. Вариант через ftp/sftp не нравится, как и с прямым редактированием файла на сервере т.к. довольно легко просто случайно ошибиться, поэтому пока думаю на каждый production-сервер завести отдельный git репозиторий, в котором хранить конфиги и подтягивать их через git pull
Просто варианты с ручными правками или перезаливками могут быть не быстры, а так можно будет обновить приложение используя
cd /var/www/app; git pull; cd /var/www/app-config; git pull - это сработает быстро, и не потребует даже кратковременной остановки приложения
Скажите, сейчас вы поняли, что именно я имел в виду и почему? Просто чтобы я мог проапдейтить вопрос
evgenybuckharev: Вопрос не в том как избежать попадания конфигов в репозиторий, а в том, как их правильно "доставлять" на сервер, если они в репозитории не находятся. Посмотрите выше ответ matperez и мой комментарий к нему, там я чуть подробнее описал причину вопроса
Спасибо, именно 12factor.net меня и натолкнуло на создание этого вопроса. Просто у меня в голове одна нестыковочка: я обновляю приложение на сервере посредствам git pull; composer install;
git pull подтягивает измененную версию приложения, которая может требовать изменения конфигурации. И тут опять, либо менять конфиги руками (что не быстро и может потребовать остановки приложения), либо подготовить sh-скрипт, который это сделает, но который тоже надо заливать на сервер, что не особо отличается от хранения main-local
Пока в голове крутится только вариант с тем, чтобы завести отдельный репозиторий с конфигами на каждый сервер, и делать на сервере git pull для конфигов. Так еще и версионирование конфигов будет. Что думаете насчет такого варианта?
Вы меня немного не так поняли. Про gitignore я понимаю, это само собой. Я имею в виду, что например в приложении появился еще один экземпляр БД, к которому есть отдельное подключение, которое надо конфигурировать. Его получается надо добавлять во всех main-local на всех серверах. На мой взгляд, лезть руками через ssh и редактировать файл "на живую" - плохой вариант, как и заливать измененный файл вручную через sftp.
Пока в голове крутится только вариант с тем, чтобы завести отдельный репозиторий с конфигами на каждый сервер, и делать на сервере git pull для конфигов
