SP
ну хочет человек странных вещей - ну ок
Size: a a a
2021 May 19
SP
что до "консистентности" и "публичных полей" - запихни эти два поля в один embedded объект и никогда не меняй значение - заменяй весь объект :)
VC
это критика альернтивы создать два поля
SP
на выходе получаешь красивый имутабельный объект у которого публичные поля и всегда все консистентно
SP
даже Алан Кей не доебется
AM
Этот гемор легко устраняется вьюшкой.
DE
А доктрина сумеет сохранять в оригинал и читать из вьюшки?
AM
Можно указать вьюшку и в неё же писать. Главное сделать is_deleted как read-only поле
AM
Максимум что сейчас из проблем могу придумать, это всякие автоматические миграции, пыховские утилиты работы со схемой бд и тп (они могут не проверять вьюха это или таблица)
DE
Вот именно. Из за нежелания where is not null придётся наворачивать целую вьюху и потом возиться с миграциями.
DE
Зато семантично :)
AM
Это было предположение, а не точная ошибка.
А вообще, многие используют автоматические миграции? Я руками стараюсь править
А вообще, многие используют автоматические миграции? Я руками стараюсь править
AD
Просто у тебя пропертей нормальных не было, вот ты и бесишься)
DE
У джентльмена не read-only проперти. Из-за этого и геморрой с консистентностью.
VC
геморой из-за непонятности какую бизнес-задачу решаем, каких бизнес-целей пытаемся достигнуть )
2021 May 20
SP
А зачем доктрине читать из вьюшки ;)
AM
Раз тут уж намёк появился.. У меня время от времени ощущение неопределённости возникает. Делаем мы, условно, чтение без доктрины и мапим на простые dto, которых в разных случаях может быть большее множество, отличающихся мелкими частями. Как в таком случае вопрос именования этих dto решать? Никак в уме не укладывается
DE
Это надо у ТС спросить, зачем ему надо кастить в бул именно в доктрину
AM
Ограничиваться парой dto с нулями или нуль-объектами тоже как-то неприятно...
DE
Ну мы же предполагаем что хотим получить. Потому так и называть можно.