Схема такая ruhighload.com/architecture.phps.jpg , схема 3: ruhighload.com/post/%D0%90%D1%80%D1%85%D0%B8%D1%82...
Идея рабочая.. Но тогда получается нужно разворачивать по nginx'у на каждом бекенде, что будет не очень красиво в архитектурном плане (где одна точка входа - на фронте и все идет через него), кроме того не очень удобно в плане масштабирования
Спасибо, про это Yii::$app->view->params['customParam'] d принципе в курсе, немного смущает вызов во view $this->params['customParam'] во многих местах, как-то это не элегантно вышлядит, вот и интересно, возможно есть вообще другой подход?
Дмитрий Воронков: т.е. идея переопределить find в классе модели и выводить в результате find свой экзепляр класса ActiveQuery, в котором и прописывать свои методы (скоупы), например у меня есть класс Node (записи) и есть 2 связи: Region (регионы со связью many-many) Block (блоки расположения со связью many-many)
в результате можно будет делать так: Node::find()->withRegions([1, 2]) (для региона 1 и 2 и всех блоков) или Node::find()->withRegions(2)->withBlocks(1) (для 2 региона и блока), где withRegions() и withBlocks() - методы переопределенного класса от ActiveQuery. Правильно вас понял?
как получаете этот $subjectsIn - массив? может лучше не хранить его в памяти вообще, а делать запрос вида SELECT * FROM table1 WHERE id IN (SELECT id FROM table2); т.е. место ... AND user_id IN({$subjectsIn}) ... переписать на ... AND user_id IN (SELECT user_id FROM `user_community` WHERE condition) ...
Дмитрий Евграфович: Правильно ли понимаю (из слов "не стоит") что конкретно в Yii вы считаете связи в БД можно не использовать, но в принципе вы за их использование? Александр Макаров - правильно ли понимаю что плюсом использования связей и внешних ключей будет "целостность данных" и удобство каскадного удаления средствами БД, т.е. уменьшение кода в afterDelete, есть ли еще "бонусы" от Yii за связи в БД (кроме связей формируемых gii) ?
Да так именно и ставил, но видимо установилось не корректно, почему? Вот еще добавил в composer.json "scripts": {
"post-install-cmd": [
"bower install"
],
"post-update-cmd": [
"bower install"
]
} - и все заработало, правильно ли понимаю что если стоит fxp/composer-asset-plugin, то можно было бы не прописывать запуск бовера?
Евгений Елчев: посещаемость около 10 000 уников в день +/- 5000 (новости). Вариант с кешем не устраивает как при проблемах с соединением каждый раз при обновлении кеша виджета сайт будет подвисать из-за curl. По идее не очень страшно - ведь это только для одного пользователя за какой-то промежуток времени. Но это потенциально трудно уловимая ошибка в будущем, да и как то это противоречит моим представлениям о красоте решения, ведь один проект не должен зависеть от другого (т.е. пусть лучше ничего не показывает, чем тормозит)
возможно вы и правы, но тогда возникает вопрос с использованием curl: там таймаут в секундах т.е. ограничительный минимум 1 сек, что много если обращаться в виджете (даже если его кешировать один раз возможны тормоза) при условии проблем с соединением. Если делать через команды (CLI по крону например), то тогда придется где-то хранить эти данные - что влечет дополнительные сложности. Не проще ли тогда использовать DAO на одном сайте, используя коннект к другой БД, чем городить огород с REST ради показа одной новости, или я чего-то не понимаю?
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Идея рабочая.. Но тогда получается нужно разворачивать по nginx'у на каждом бекенде, что будет не очень красиво в архитектурном плане (где одна точка входа - на фронте и все идет через него), кроме того не очень удобно в плане масштабирования