Я сначала создавал список новых Entity для формы, но с ними столько проблем появилось, что решил отказаться от этой идеи. Это фактически переход на ручную обработку всего этого дела.
Сейчас у меня только 1 момент, который я скорее к багу отношу. Доктрина при удалении последнего элемента запускает процесс удаления коллекции из базы данных, не проверяя их идентичности.
Arik: прекрасно работает) он как раз указывает, чтобы данный атрибут не помещался в сценарий. А сценарии, насколько я понял, это всего лишь списки безопасных атрибутов, которые сужают список из rules().
если имеются атрибуты вроде 'created_at' и 'updated_at', но они не указаны в rules или текущем сценарии, то они тоже не будут загружаться, но могут быть установлены поведением, прицепленным к модели, или указаны вручную: $model->updated_at = time();
Arik: нет, только атрибуты, указанные для текущего сценария, будут безопасными. По умолчанию сценарии генерируются через правила, указанные в rules(). Но можно и вручную прописать в виде массивов в scenarios(). Если в rules() указать [['name', 'phone', '!admin'], 'string'], то только 'name' и 'phone' будут загружены через load()
"которые пользователь не имеет права присылать" - это атрибуты, которые не будут массово присвоены, но будут проверены на правильность, то есть метод load() и подобные не смогут их изменить, только "вручную" в контроллере (или модели) надо будет прописывать что-то вроде $model->nameOfAttribute = $value; не важно, откуда данные взялись, хоть из базы вы их загрузите, модель это не волнует) В вашем случае вроде как сценарии наиболее подходят, если есть несколько вариантов менять поля. Если очень хочется, можно вручную атрибуты присваивать вместо load() :)
Такое ощущение, что вы не разобрались в Yii2, но уже начали переписывать его "под себя". Если внешние ключи установлены в таблицах базы, Gii отличный код генерирует, со всеми связями и проверками. Я из правил только ссылку на узера заменяю поведением (BlameableBehavior), даты создания/обновления на TimestampBehavior, boolean надо подправить (gii его как integer подписывает) ну и небезопасные атрибуты пометить значком "!" (которые пользователь не имеет права присылать).
Вроде достаточно 'attribute' и filter' задать, название и значение через связь из модели должны выбираться, формат по умолчанию 'text'. А вообще в документации про gridview всё это подробно описано)
У майкрософта типичная английская проблема - род слов согласовать не могут, выдает что-нибудь в духе "Сметана обезжиренный". У Яндекса с этим получше, Гугл тоже сойдет. Вообще начинаю склоняться к ручному переводу, потом всё равно запарюсь исправлять всё)
padlyuck: ок, спасибо) а то я давно уже проверял, что записи защищены от удаления, может быть нафантазировал и нормальную обработку этой ситуации) Вообще неплохо было бы, если бы она была...
Меня интересует, должен ли Yii2 сам выводить сообщение о неудавшемся удалении, или он у всех выбрасывает ошибку, и надо вручную ее отлавливать? Вроде как первое логичнее, так как Yii2 запрашивает схему базы данных и видит все триггеры.
Нет. Во-первых такой триггер позволяет удалять связанные записи, а я их хочу защитить от удаления, во-вторых такой триггер даже не поставится, так как food_id NOT NULL.
Раз он ругается, что файл уже существует, я бы попробовал вручную его удалить и запустить скрипт еще раз) Но я с линуксами редко общаюсь, после винды там работа с файлами не особо очевидной кажется.
Пума Тайланд: вы написали "Справки правильные посольства не проверяют", поэтому я и не согласился) иногда всякие стажеры проверяют всё, до чего смогут дотянуться)
Пума Тайланд: это если по умному сделать) а если кто-то "додумается" указать реальную компанию или официально несуществующую организацию ;) всякие стажеры иногда проявляют такое рвение, что могут и все предоставленные данные перепроверить) у меня разок в аэропорту девочка спросила всё, что могла и даже что не должна была по правилам проверять...
данное неравенство вернет false, числа будут признаны разными)
если вы храните числа с точностью до тысячных, погрешность должна быть меньше тысячных. в базе числа 7,889 и 7,888 явно должны быть не равны.
а если в результате вычислений получилось 1000.237999715, то оно должно быть признано равным вашему 1000.238
Пума Тайланд: посольства каких стран? Отказы бывают и при вроде бы идеальных документах, и даже при наличии приглашения. То, что бронь не подтвердилась, еще не повод обвинять вас в злом умысле) Плюс это легко исправить, сделав новую бронь, и повторно подав документы. Хотя проще обратиться в другое посольство.
Даже если вы получите визу, а потом вам ее обнулят из-за отмены брони отеля, в черный список вас также не внесут) Тут действительно нужны большие основания, чем забывчивость или смена отеля на что-то другое. Можно даже поддельную медицинскую страховку объяснить, что у мошенников купили) А вот поддельное место работы вряд ли)
Пума Тайланд: небольшая просрочка и нарушение сроков пребывания в конкретных странах, это, скорее, мелкие нарушения, а предоставление поддельных документов для каких-нибудь немцев уже практически преступление. Это примерно как использование в качестве обратного билета неоплаченной брони и поддельного билета. Подделка тоже может прокатить, но в случае проверки в страну вас не пустят. Лично у меня достоверность обратных билетов никогда не проверяли, но это ведь не повод считать, что так будет всегда)
Сейчас у меня только 1 момент, который я скорее к багу отношу. Доктрина при удалении последнего элемента запускает процесс удаления коллекции из базы данных, не проверяя их идентичности.