наверное, добавить что-то вроде WHERE id=id а id как параметр передавать?

т.е. UPDATE YourTable SET Field1 = Field1 + 1 WHERE id=id

обоснование то будет?

1. излишнее усложнение не несущее никакой пользы кроме экономии нескольких сотен байт на ордер 2. надо добавлять проверки аля "если уже было удалено бла бла". 3. надо усложнять выборки и "помнить об этом".

с другой стороны можно сделать у пользователя метод rememberAddress(Address $address) и повесить на доменный ивент OrderCreated

абсолютно независимая логика управления адресами, сохранение истории

пилится за час-два

потому рекомендовать заведомо сложный и ненужный способ - так себе идея

Причем тут экономия байт вообще. Хочешь сказать, что нормализация - это типа для экономии байт? А проверки и так придется, особо если пользователь поменяет адрес до постановки заказа в логистику.

по поводу же неймспейсов типа VO - это вообще раковая опухоль не не сущная никакой смысловой нагрузки, не подсказывающая где что искать и т.д.

Причем тут экономия байт вообще. Хочешь сказать, что нормализация - это типа для экономии байт? А проверки и так придется, особо если пользователь поменяет адрес до постановки заказа в логистику.

вообще-то да, нормализация это экономия байт

а так как у тебя там софт делит - тебе не нужны там внешние ключи

А, тогда больше нет вопросов ;)

ну если ты почитаешь "историю" того как возникла идея RDBS то ты узнаешь что сегодня дальше 3-ей нормальной формы - это экономия байт которая была актуальна в 70х

а сейчас лучше решать проблему связанности данных на уровне быза

более того - если у тебя есть 2 несвязанные сущности - то нормальзация тут не причем

Ну да, адрес доставки у пользователя и в заказе - это совсем разные сущности

да и целостность данных полностью вешать на базу у тебя всеравно не выйдет (если без процедур и тригеров) а потому зачем вообще заморачиваться

Ну да, адрес доставки у пользователя и в заказе - это совсем разные сущности

именно так, или это типа сарказм был? Если так - то то, является ли сущность одной и той же, или же какие у них взаимоотношения надо определять не по названиям а выделяя роли и обязанности этих сущностей.

обязанность сущности UsedAddress которая хранит последний адрес - это нужно покупателю что бы он потом меньше тратил время при оформлении заказа. В случае же с заказом адрес доставки там вообще VO а не сущность. Потому это вообще разные штуки

Почему же в заказе - это VO, а у пользователя - сущность?

С чего такое уважение пользователю? ;)

Почему же в заказе - это VO, а у пользователя - сущность?

потому что у тебя есть список адресов, и ты можешь ими управлять. Мы не настолько их "уважаем" что бы скажем им репозиторий свой делать - можно работать в контексте юзера с ними (типа юзер корень агрегата сущностей), но и коллекцию VO мы делать как бы можем но это будет усложнять операции удаления.

а в заказе "адрес" это просто поле. Оно никогда не поменяется (либо заменится на другое продавцом)

интересный способ выбора VO vs Entity - "что бы удалять удобнее было" ;)

интересный способ выбора VO vs Entity - "что бы удалять удобнее было" ;)

выбор делать что-то VO или Entity строится на основании одной единственной вещи. Нужно ли тебе отличать один адрес от другого или нет. То есть в контексте адресов нас интересует именно само значение адреса. А в контексте пользователей нас интересует конкретный адрес, его идентификатор. Дабы иметь возможность его удалить. Ты можешь конечно это реализовать тем что сделаешь еще один VO который нам надо будет найти в коллекции и удалить но это даже звучит тупо

то есть если у тебя есть два VO с одинаковым адресом, если нам пофиг и мы можем сравнить по значению - это VO. А если нам не пофигу и это одинаковые адреса разных пользователей - то тут уже надо идентификатор заводить и значит это сущность

еще момент

"последние использованные адреса" юзера и "адрес заказа" находятся в совершенно разных контекстах

а потому глупо вводить общую зависимость между ними

ага, я понял, ты адрес рассматриваешь как набор какого-то абстрактного текста

ага, я понял, ты адрес рассматриваешь как набор какого-то абстрактного текста

в контексте ордера он мне именно такой и нужен. Может еще включать координаты и тд. это не столь важно.

мне важно что с этим адресом никогда и ничего не приключится

и он останется в ордере до скончания интернета

вот в контексте ордера тебе скорее всего потребуется привязка к адресному справочнику

вот в контексте ордера тебе скорее всего потребуется привязка к адресному справочнику

эм... нет)

есть координаты

этого достаточно

ну то есть что такое "адресный справочник" и какое отношение он имеет к ордерам?

кооринаты? ;) для отправки заказа?

да, ты можешь по координатам получить и полный адрес и zip код и все такое

ну или эта инфа у тебя уже есть в VO

имея страну и zipcode для вычисления стоимости доставки например знать ничего не надо

ну разве что вес посылки

всеравно ты будешь это все через сторонние сервисы разруливать а стало быть связи строить несчем

ну и опять же - ЕСЛИ у нас придет требование при котором адрес должен стать сущностью - не вопрос. Он станет сущностью в контексте заказов и все.

да... это круто вместо того, что бы привязаться к справочнику идентифицирующему место доставки - хранить координаты и искать сервисы, где это отресолвить

появится сущность DeliveryAddress а в контексте юзеров будет UsedAddress

да... это круто вместо того, что бы привязаться к справочнику идентифицирующему место доставки - хранить координаты и искать сервисы, где это отресолвить

я так понимаю что ты никогда не сталкивался с высокой связанностью на уровне базы данных потому что все делают сущностями и лепят связи всего со всем

короч как знаешь, дело твое

М... ты представляешь, например, что такое ФИАС?

можешь делать как сущность и лепить общую зависимость между модулями

М... ты представляешь, например, что такое ФИАС?

не работаю в СНГ

видимо какой-то кадастр адресов, там есть апишка

опять же в требованиях ничего небыло - не имею привычки придумывать то чего не будет на проекте

Ладно, давай упростим задачу. У тебя есть 10 точек выдачи. Получить товар можно в любой. У точки выдачи есть адрес. В заказ будешь впихивать все эти данные и пихать в VO?

Ладно, давай упростим задачу. У тебя есть 10 точек выдачи. Получить товар можно в любой. У точки выдачи есть адрес. В заказ будешь впихивать все эти данные и пихать в VO?

это не адреса, это точки выдачи. Ты будешь привязывать доставку к точке выдачи. И это будут сущности. И у каждой адрес как VO ))

более того

это может быть как часть информации о доставке и у тебя может быть больше одной стратегии для оной

Чем точка выдачи с адресом отличается от моего офиса с адресом? ;)

Чем точка выдачи с адресом отличается от моего офиса с адресом? ;)

тем что адрес доставки в контексте ордера это VO а точка выдачи это сущность в контексте модуля ордера

потому что точка выдачи будет иметь свои какие-то дополнительные штуки, может свою юр инфу какую и т.д. может еще чего

ну и еще - у тебя явно надо на уровне "точки выдачи" иметь список заказов относящихся к ним

то есть налицо отношение двух сущностей

а не "данные какой-то сущности"

Не понял, окей... было у фирмы 10 точек выдачи, а потом они взяли, и открыли точку выдачи у двери каждой квартиры ;)

Почему точка выдачи - это сущность, а квартира - внезапно перестает ей быть.

Не понял, окей... было у фирмы 10 точек выдачи, а потом они взяли, и открыли точку выдачи у двери каждой квартиры ;)

а потом все закинулись еще кислотой и поехали в ближайший публичный дом

ERROR: S client not available

Почему точка выдачи - это сущность, а квартира - внезапно перестает ей быть.

потому что нас не интересует в контесте заказа цикл жизни какой-то там квартиры. Нас интересует информация о том куда доставлять в данный момент.

и даже если дом снесут информация должна сохраниться

если у тебя сущность может быть только создана и она имутабельна всегда - это VO

даже не так

если точку выдачи закроют - информация тоже должна сохраниться

все объекты VO по умолчанию. Иногда VO мало и нужны сущности

если точку выдачи закроют - информация тоже должна сохраниться

она и сохранится, только вместо soft delete у тебя будет статус "закрыто"

ну так и у квартиры будет статус "дом снесен" ;)

ну так и у квартиры будет статус "дом снесен" ;)

но эта информация не нужна бизнесу

нас как бизнес по доставке вполне себе интересует цикл жизни наших точек выдачи но вообще не интересует цикл жизни квартир или домов

ключевое слово НАШИХ точек и ЧУЖИХ квартир

в целом все от домена зависит. Если ты скажем не каталог товаров делаешь а скажем систему ЖКХ то да, адрес будет сущностью

Равно как бизнесу не нужна информация, что заказ 555 сделанный 10 лет назад был доставлен в точку выдачи, которая сейчас закрыта

Равно как бизнесу не нужна информация, что заказ 555 сделанный 10 лет назад был доставлен в точку выдачи, которая сейчас закрыта

эта информация может пригодится когда ты будешь анализировать откуда чаще забирали заказы

если скажем ты интернет магазин одежды делаешь, у тебя основной поток заказов будет как раз таки через точки выдачи товара (если есть возможность примерить и отказаться например)

А с чего ты взял, что не потребуется анализировать распределение доставок по округам, например

и если тебе 3 года назад пришлось закрыть 10 точек потому что денег небыло а сейчас ты хочешь расширяться - эта информация может тебе помочь

А с чего ты взял, что не потребуется анализировать распределение доставок по округам, например

у тебя есть информация - анализируй.

для этого не нужно делать адрес сущностью)

Ну так такой же ответ про точку выдачи. Есть информация в VO - анализируй ;)

короч ладно, пойду работать. Просто рекап: - VO по дефолту. Если можно не делать сущность а делать VO - делай VO. - сущности если нужен цикл жизни объекта - сервисы если логика не укладывается в рамках сущности или VO или надо просто изолировать отдельные бизнес правила (или инфраструктуру)

Ну так такой же ответ про точку выдачи. Есть информация в VO - анализируй ;)

это не так удобно. А вот с VO - легко. Особенно если есть координаты - можно загрузить в эластику и через кибану карту получить)

ребят подскажите, пожалуйста, если знаете `public function incrementQuantityByField($field, $id, $em) { $sql = " UPDATE task SET $field=$field+1 WHERE id=$id; "; $stmt = $em->getConnection()->prepare($sql); $stmt->execute(); return $stmt->fetchAll(); }` ошибка вылетает следующего формата: [PDOException] SQLSTATE[HY000]: General error

с центрами масс и все такое

не знаете почему?

(в сторону) жизненный цикл... это про переименовывание улиц? .. ;)))

таблица называется task поле в ней передаю как параметр ну и ID тоже

(в сторону) жизненный цикл... это про переименовывание улиц? .. ;)))

это часть жизненного цикла улиц да. Имя может поменяться но эта улица остается именно этой улицей. И в другом горое может быть такая же улица. Но нас не интересует жизненный цикл улиц в контексте доставки заказов.

абстрагируйся

А в контексте анализа доставок - интересует ;)

А в контексте анализа доставок - интересует ;)

нет, там координаты ценнее

с точностью до 100 метров