а) для более быстрого поиска по продуктом
б) для поддержки локализаций, допустим, наименования продукта на нескольких языках и, при этом, продавец сам выбирает, на каких языках написать. Для этого, без nosql базы, я вижу 2 решения - либо токены (не нравится), либо json поле. Ни то ни другое особо не нравится.
Он мне не совсем кажется самым верным, так как в этом случае все равно придется переделывать вызов каждого хелпера. А как эту переменную в хелперах учитывать? Ведь они создаются динамически на основе маршрутов.
По-моему в вопросе все описано понятно. Есть именованые маршруты, допустим, :index, :project и так далее. В общем случае эти маршруты выдают урлы вида /?client_id=123, /?project_id=321.
Сейчас, для одного определенного домена надо сделать урлы вида /123, /projects/123. Для этого определенного домена добавлены свои маршруты с использованием constraints. У новых маршрутов имена построены по принципу prefix+имя_оригинального маршрута. Надо сделать так, чтобы при запросах к данному домену, стандартные хелперы выдавали url, сформированый именно для этого домена.
То есть, допустим, action редиректит на index_path. Надо сделать так, чтобы не меняя action, для определенного домена, index_path вызывал бы prefix_index_path
Ну, nginx - это само собой, как и кеширование. В данном случае, запросы на запись, так что приложение работает в любом случае. Просто тот же php дает больше одновременных соединений. Знаю, что некорректно сравнивать, но все же :)
Виктор Ablebeam: да, тонкостей и ситуаций может быть много. Но если делать все правильно, то и разгребать в итоге легче :) Хотя заранее надо, конечно, думать больше
относительный путь-то тоже разный получается. А такое решение было выбрано, так как использовать симлинки для файлов модели в трех приложениях, которые используют одну и ту же модель, мне кажется совсем уж некрасивым хаком
АК: Собственно, когда начал использовать Kibana4, в горове прозвучало "а неплохо было бы иметь такой же анализ логов nginx". Оставался только идеологический вопрос, не является ли перенос логов веб-сервера в elasticsearch чем-то сильно неправильным
а) для более быстрого поиска по продуктом
б) для поддержки локализаций, допустим, наименования продукта на нескольких языках и, при этом, продавец сам выбирает, на каких языках написать. Для этого, без nosql базы, я вижу 2 решения - либо токены (не нравится), либо json поле. Ни то ни другое особо не нравится.