Михаил Осин: Не совсем понимаю, как это применимо? Я не пишу java приложение. Я просто установил эластик, как отдельное приложение на сервер. Работа с ним идет через http.
DevMan: Не все. Но вы же понимаете, что джун - это программист с уже имеющимся опытом. Маленьким, но опытом. Это не студент-недоучка, который ничего не значет. До джуна еще тоже надо дорасти.
65536: Накладок не будет, если при проектировании кода вы это учтете.
Например: у вас есть покупателей и модель заказов, связанные AR связью и ключем в бд. При удалении покупателя вам надо удалить его заказы. А при удалении заказа, который еще не был отправлен, надо увеличить счетчик товара на складе.
Как это выглядит? В Customer::afterDelete() вы выбираете все его заказы, проверяете, какие из них не были отправлены увеличиваете соответствующий им счетчик. Без ключей этот подход прекрасно работает.
Если же у вас будет использоваться удаелние по ключу, то такой подход не сработает т.к. на момент срабатывания afterDelete() заказов пользователя уже не буедт в бд (база их удалит вместе с пользователем). Поэтому эту обработку надо выполнять в Customer::beforeDelete(), после всех проверок. Тогда все нормально будет работать.
Понятно, что пример надуманный и что те же транзакции решат эту проблему. Но если вы пишите большой проект и работаете не один, можете ли вы гарантировать, что все разработчики во всех местах будут удалять все правильно? Ключи этого не гарантируют, но они гарантируют, что у вас в бд не буедт заказов, чей покупатель был удален.
Плюс ключи помогают еще и при записи. В этой же схеме бд не даст вам создать заказ, для которого указан id-гник несуществующего покупателя.
>> признаться, никогда не пробовал бд связи использовать. в основном из соображений того, чтобы не размазывать логику между кодом и какой-то фичей субд. лучше все будет в одном месте и наглядно (на правоту даже не претендую))
Во-первых: это не какая-то фича, а сама суть реляционной(!) бд. Плюс чтобы вы не размазываете логику, она вся в вашем коде. Ключи нельзя назвать логикой работы. База просто гарантирует целостность данных в ней.
Я из похожих соображений не использую тригеры т.к. там уже действительно есть логика.
65536: А я и не говорил, что это единственный критерий целостности. Но обязательный. Вопрос был: "Надо ли использовать ключи, если связи все равно дублируются в коде?" Я ответил, что да, стоит.
>> Если мы готорим только о БД, то есть тригеры. Если мы говорим о системе в целом, то это делается в моделях, но к бд это уже не имеет никакого отношения.
>> я думаю более универсальный вариант когда база располагается намертво за заданным апи. то есть никаких редактирований в обход вообще
Тут я с вами полностью согласен. Это буедт идеальный вариант. Но есть куча тонкостей. Например огромные запросы, для которых лоигку надо в хранимки выносить. Тут уже логика в модели не поможет. Или в стадии активной разработки часто надо ручками данные менять.
Вообще это очень обширный вопрос разделения логики между приложением и базой. Это плодотворная тема для холиваров и немало копий было сломано в спорах на эту тему. Поэтому я еще раз подчеркну, что я согласен с вами: ключи обязательное средство, но не единственное.
дима кубитский: >> да вот именно там и описано что обновление используя пут-распространённая практика, но почему всё же лучше делать наоборот.
However, it's recommended to keep PUT requests idempotent. It is strongly recommended to use POST for non-idempotent requests. <<
Я все-таки не совсем понял, в чем претензия к распространенному подходу? Тут рекомендуется использовать PUT для идемпонентных запросов, а POST для неидемпонентных.
Если я отправляю два одинаковых запроса на создание, то они будут неидемпонентными т.к. для каждого будет создана новая сущность. При этом запросы на изменение с одинаковыми параметрами приведут к повторному обновлению полей сущности до тех же значений т.к результат будет одинаковым и запрос идемпонентный. Все-таки выходит, что создание - post, а редактирование - put.
>> представьте что это у вас иерархия в виде дерева каталога, сразу станет очевидно что вам необходимо указывать проджект айди. <<
Вот я и хотел избавиться от полной иерархии. Т.к. путь, например, к созданию лейбла для тикета выглядит так: POST /projects/:project_id/sections/:section_id/tickets/:ticket_id/labels
При этом серверу не надо знать ничего про раздел, только про тикет и проект.
>> то связанно со спецификаций, позволяющей в пост запросе отправлять не все данные объекта, в отличии от например пут, где необходимо высылать все данные объекта.<<
В чем же это заключается? И там и там параметры отправляются в теле запроса и я волен как угодно формировать их список.
>> 3. С названия вьюхи видно, и никто кастомные имена не отменял. По-моему толком ничего не надо, всё нужное ему видно и так.
То, что это очевидно вам, не значит, что это будет очевидно человеку, не работавшему с yii
>> А зачем там проверки прав ?
Я выше пример приводил уже.
Влад Волынец: И не говорю, что использовать шаблонизатор нельзя. Просто, как по мне, гемороя это создает больше, чем пользы.
- Надо выеживаться, чтобы дать доступ только к папкам вьюх. Переопределять их не можно, но не стоит, если этот код потом поддерживать кому-то. Тем более вы же не через ftp организовываете взамидействие, а через git?
- Плюс структура может постоянно менять: добавляются контроллеры, экшены, выносятся общие части в partial вьюха, модули.
- Верстальщику надо объяснить, как yii со вьюхами работает, какая вьюха куда относится.
- Коментарыи о доступных переменных и для php надо будет оставлять типа /** @var User[] $users */. Но для php IDE по ним еще и автокомплит сделает (не в курсе шаблонизатор подерживает автокомплит?), а ненадо будет поля объекта описывать и потом следить за актуальностью.
Опять таки, сложные проверки прав через checkAccess() вы тоже из шаблонизатора будете делать?
Я не говорю, что шаблонизатор не нужен, но на мой взгляд, для Yii он мало пользы принесет. Может для клиентских sibglepage приложенй, где все в одном месте лежит, он и подойдет.
Денис Иванов: >> "Плюс перевод надо делать в модели, а во вьюху отдавать уже переведенный текст." А можно пруф линк на это? Или аргументы, почему этим должна заниматься модель, если мы говорим об обычном i18n
Пруфов не приведу, но аргументировать могу. Замечу сразу, это касается перевода полей модели, а не перевода статичных текстов из вьюхи. Просто тексты, конечно же надо переводить во вьюхе.
- Перевод в модели позволяет делать это в одном месте. Если вы выводите название товара в разных местах, зачем везде лепить перевод?
- Перевод в модели скрывает реализацию. Если вы решите перенести эту фразу в другой словарь, вам не надо будет бегать по всему коду и менять это.
- Все-таки это не логика отображения, а логика самого приложения. Ведь мы меняем не просто внешний вид названия, а фактически само название.
