null. Но как понять было ли оно реально засечено со значением null или это дефолтный нал?
А на что это у тебя влияет? Ну допустим у тебя дефолтное значение и там и там null. Какая разница откуда он у тебя пришел?
Предположим в dto у меня есть toArray который возражает ассоциативный массив (свойства dto объекта) я его кладу сразу в модель и сохраняю. Таким образом мои не заполненные поля с null попадут в таблицу. Но такого быть не должно.
а если они у тебя не заполнены, там что должно быть в БД по твоей логике вместо null?
Я так понимаю речь о дто на апдейт, и как определить действительно ли там нулл надо поставить, или этот нулл - потому что в дто не передали значение Можно в сеттере писать изменённые поля в отдельный массив, и проверять их по необходимости каким-нибудь isDefault методом... Или совсем не пускать дефолтные данные в toArray.. В зависимости от ситуации
ну а на что это повлияет? если по логике важно уметь отличать состояние "нет данных" от состояния "по умолчанию", то наверное, поле в бд должно быть not null. А если разницы нет, то можно просто писать null вне зависимости от того, это "нет данных" или это "данные по умолчанию"
В точку. Но решение мне кажется очередным костылем.
Тем, что данные могут быть в базе, но не в пришедшем апдейт реквесте И если делать тупой ->fill(dto->toArray()) - не пришедшие данные будут заменены на null в базе, что не совсем корректно
Не знаю решения лучше, в защиту этого - лара использует нечто подобное в моделях, isDirty, например
а, понял. Ну как по мне лучше мониторить измененные поля и только их в toArray возвращать
Вообще такое заполнение полей модели это плохая практика) Зачем тебе дто вообще, если ты его свойства завязывать на поля базы данных ) Дто - это абстракция, которая должна просто принять данные и доставить до точки, где эти данные будут использованы. А у тебя получается, что если изменится название поля в бд, то твоя дто станет причиной проблемы)
Окей, поменяй ->fill на целую кучу model->field1 = dto->getField1 Суть вопроса сабжа останется такой же, только пример раздуется)
По сабжу выше ответили)))
Ну по использованию филов согласен, я использую это напрямую с реквестами лары в тех модулях, которые нужно "присрать" по быстрому. Для прототипирования маленьких приложулек, если угодно
Мы в 2023, геттеры в ДТО уже не нужны
Потому что есть readonly
Это я знаю, а как свойства извлекать без геттера ?)
Зачем их «извлекать», если они публичные?
Типо делаем readonly класс свойства объявляем публичными, автомашин используем как $class->property?
Кто такой «автомашин»?
Не было такого ) ты о чем ?))
«У меня все ходы записаны»©
Обсуждают сегодня