Ребят, как можно через Eloquent сделать такой запрос? UPDATE `users` SET `bonus` = (`bonus` - 5) FROM `users_promocodes` WHERE `users_promocodes.user_id`= `users.id` AND `users_promocodes.promocode_id` = 10` Модели: User, Promocode и UserPromocode

т.е. обновить у всех?

Есть таблица `users`, `promocodes` и `users_promocodes`. Ключи `users_promocodes` такие: `user_id` (`users.id`) `promocode_id` (`promocodes.id`) Хочу сменить поле `users.bonus` у всех юзеров, у которых, promocode_id = 10

я догадался

а что если у какого-то юзера бонус равен.. 3?

Ну, там уже немного по-другому отнимается, с этим разберусь :) Не могу понять, как это всё в Laravel сделать через Eloquent

просто это важный вопрос

ты пытаешься бизнес-операцию сделать через массовый update

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

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

это я конечно фантазирую. но на вполне реальные темы.

Всё гораздо проще. Промокод увеличивает суточный лимит на получение ежедневного бонуса (у каждого он один по умолчанию, промокод прибавляет к этому числу ещё), нужно сделать так, чтобы после удаления промокода лимит отнимался

т.е. когда не у конкретного юзера промокод удаляют а когда деактивируют сам промокод?

Да

т.е. юзеров так много, что не хочется перебирать всех? :)

Да

мм.. чот не дает.

а вот. Мое мнение что все равно надо у каждого отдельно этот промокод убирать. А вы как думаете?

Бегло посмотрел этот yii-shop. Ну такое... я не уверен что такое именно DDD, но это точно не оно. Где persistance ignorance? Где framework agnostic? Где VO в конце-концов? Где защита инвариантов? Это чисто техническая сторона. По иделогической будет еще больше вопросов. Те же контексты.

А я и никому не говорил про DDD. Это просто проект на ООП с уклоном на SOLID с сервисным слоем. Вы здесь сами о DDD придумали и сами друг с другом на эту тему фанатично поругались. Выглядит забавно :) Prersistance ignorence здесь во всём кроме наличия extends ActiveRecord. Но это наличие никак на ядро не влияет, и напрямую в бизнес-коде не используется. Именно в доменом коде полное ignorence. Framework agnostic в ядре во всём кроме использования встроенных моделей форм в качестве DTO и поведения для загрузки фотографий. Мета-теги, привязки категорий и меток, значения атрибутов, фотографии товаров и подобные внутренности агрегатов сделаны в виде VO. Защита инвариантов имеется практически во всех агрегатах и их запчастях. Про контексты уже поговорили. На таком малом объёме в разбиении на контексты ещё нет смысла.

А я и никому не говорил про DDD. Это просто проект на ООП с уклоном на SOLID с сервисным слоем. Вы здесь сами о DDD придумали и сами друг с другом на эту тему фанатично поругались. Выглядит забавно :) Prersistance ignorence здесь во всём кроме наличия extends ActiveRecord. Но это наличие никак на ядро не влияет, и напрямую в бизнес-коде не используется. Именно в доменом коде полное ignorence. Framework agnostic в ядре во всём кроме использования встроенных моделей форм в качестве DTO и поведения для загрузки фотографий. Мета-теги, привязки категорий и меток, значения атрибутов, фотографии товаров и подобные внутренности агрегатов сделаны в виде VO. Защита инвариантов имеется практически во всех агрегатах и их запчастях. Про контексты уже поговорили. На таком малом объёме в разбиении на контексты ещё нет смысла.

> по SOLID но это не точно

А я и никому не говорил про DDD. Это просто проект на ООП с уклоном на SOLID с сервисным слоем. Вы здесь сами о DDD придумали и сами друг с другом на эту тему фанатично поругались. Выглядит забавно :) Prersistance ignorence здесь во всём кроме наличия extends ActiveRecord. Но это наличие никак на ядро не влияет, и напрямую в бизнес-коде не используется. Именно в доменом коде полное ignorence. Framework agnostic в ядре во всём кроме использования встроенных моделей форм в качестве DTO и поведения для загрузки фотографий. Мета-теги, привязки категорий и меток, значения атрибутов, фотографии товаров и подобные внутренности агрегатов сделаны в виде VO. Защита инвариантов имеется практически во всех агрегатах и их запчастях. Про контексты уже поговорили. На таком малом объёме в разбиении на контексты ещё нет смысла.

> На таком малом объёме в разбиении на контексты ещё нет смысла. тут есть два момента: 1. чем плохо разделение на более мелкие контексты на схожем объеме логики? кода больше? да не особо. Сложнее? опять же не особо. 2. У меня были сценарии когда требовалось большее разделение на относительно небольшом проекте и связано это было с вайтлейблингом и кастомизацией логики в зависимости от нужн бизнеса.

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

и насколько эти контексты выходят "большими"

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

ведь если со стороны бизнеса только один человек это еще не означает что роль одна

Все паттерны - это просто примеры того, как разные задачи решают другие люди. Если что-то выглядит подходящим и даёт профит, то внедряю. Если кажется, что нужно разделение и что оно упростит код - делю. Если не кажется и всё удобно и так - не делю. Каждый решает сам как ему будет удобнее. Как всегда говорю, архитектуру придумали для упрощения сложного кода, а не для усложнения лёгкого.

А я и никому не говорил про DDD. Это просто проект на ООП с уклоном на SOLID с сервисным слоем. Вы здесь сами о DDD придумали и сами друг с другом на эту тему фанатично поругались. Выглядит забавно :) Prersistance ignorence здесь во всём кроме наличия extends ActiveRecord. Но это наличие никак на ядро не влияет, и напрямую в бизнес-коде не используется. Именно в доменом коде полное ignorence. Framework agnostic в ядре во всём кроме использования встроенных моделей форм в качестве DTO и поведения для загрузки фотографий. Мета-теги, привязки категорий и меток, значения атрибутов, фотографии товаров и подобные внутренности агрегатов сделаны в виде VO. Защита инвариантов имеется практически во всех агрегатах и их запчастях. Про контексты уже поговорили. На таком малом объёме в разбиении на контексты ещё нет смысла.

Посраться за DDD любимое дело в этом чатике :) Отвечая вам: 1. Persistance Ignorance: дальше слова кроме не читал 2. Framework agnostic: см. пункт 1 3. Value Object: По вашей наводке открыл класс Photo... Photo::setSort() ... 100% VO 4. Защита инвариантов: $f = fopen('php://memory'); $p = new Product($f, ... $repository->save($p); // Good deal, bro!

код в принципе такой себе... но это больше отсылка к говнищу под названием юи2. Портит картину напалмом просто

1. Хотите читайте, хотите - нет. Доменный код здесь всё равно игнорирует хранилище. 2. См. пункт 1. 3. Фото получилось вложенной сущностью. Так тоже можно, если Вы не в курсе. 4. С Yii 2.0.13 после моего Pull Request это можно переписать на конструкторы.

1. Хотите читайте, хотите - нет. Доменный код здесь всё равно игнорирует хранилище. 2. См. пункт 1. 3. Фото получилось вложенной сущностью. Так тоже можно, если Вы не в курсе. 4. С Yii 2.0.13 после моего Pull Request это можно переписать на конструкторы.

3. А кто сказал что нельзя? Я только говорю что это не VO 4. Шта? Причем тут конструкторы? В вашем коде можно передать любые данные в сущность, что приводит к её невалидному состоянию.

3. А кто сказал что нельзя? Я только говорю что это не VO 4. Шта? Причем тут конструкторы? В вашем коде можно передать любые данные в сущность, что приводит к её невалидному состоянию.

3. ну она ж внутри себя может валидировать это мемарю всю, пфф)

передать любые данные ок, сущность должна их проверить)

конечно приятнее туда передавать VO

Так в том то и дело что оно ничего не валидирует

а не файловый дескриптор на память, лол)

Пример специально для абсурдности привел

Вообще, если вдуматься то Framework Agnostic автор шикарно показал в четвертом пункте :) Даешь PR в Framework чтобы что-то переписать в домене. Хотя я так и не понял что...

Все паттерны - это просто примеры того, как разные задачи решают другие люди. Если что-то выглядит подходящим и даёт профит, то внедряю. Если кажется, что нужно разделение и что оно упростит код - делю. Если не кажется и всё удобно и так - не делю. Каждый решает сам как ему будет удобнее. Как всегда говорю, архитектуру придумали для упрощения сложного кода, а не для усложнения лёгкого.

а если интуитивно кажется что профита не будет а профит будет?)

как узнать?

если не попробовать?)

ведь далеко не все в этом мире так просто

3. А кто сказал что нельзя? Я только говорю что это не VO 4. Шта? Причем тут конструкторы? В вашем коде можно передать любые данные в сущность, что приводит к её невалидному состоянию.

Сущности здесь заполняются только через юзкейсы, данные в которые поступают из DTO. Если провалидирован сам DTO, то копипаста этих же проверок форматов не несёт добавочного смысла. Про варианты валидации обсуждали в http://yiiframework.ru/forum/viewtopic.php?f=34&t=36725&start=20#p188218

3. А кто сказал что нельзя? Я только говорю что это не VO 4. Шта? Причем тут конструкторы? В вашем коде можно передать любые данные в сущность, что приводит к её невалидному состоянию.

А если хотите полного драйва с блэкджеком и VO, то вам сюда: http://www.elisdn.ru/blog/104/domain-entities-modelling

чёт в примере репозиторий дохрена умеет)

явно больше, чем ему положено :)

Вообще, если вдуматься то Framework Agnostic автор шикарно показал в четвертом пункте :) Даешь PR в Framework чтобы что-то переписать в домене. Хотя я так и не понял что...

Это просто проект на просто фреймворке. Если нужно Framework Agnostic, то это делается вынесением интерфейсов и переходом на маппер.

trait ActiveQueryTrait я бы за такое убивал. медлеенно, наслаждаясь процессом

по диагонали почитал... ну говно же. Зачем людям это показывать? что бы было больше жертв с юи головного мозга?

Вообще, если вдуматься то Framework Agnostic автор шикарно показал в четвертом пункте :) Даешь PR в Framework чтобы что-то переписать в домене. Хотя я так и не понял что...

Я про PR для использования обычных конструкторов new Order(...) вместо статических Order::create(...) в AR.

public function addPhoto(Photo $photo): void { $photos = $this->photos; $photos[] = $photo; $this->photos = $photos; }

серьёзно?)

Я про PR для использования обычных конструкторов new Order(...) вместо статических Order::create(...) в AR.

возможно как раз таки статические конструкторы лучше)

в контексте php

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

приятно наблюдать даже

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

почитать комменты, подумать, почему код хейтерам не понравился) мозг включить, например. На вскидку, можем сие предложить.

можно я на 30 секунд вклинюсь с тупым вопросом, но меня переклинило и я жестко туплю, в контексте стратегии и пеймент-процессинга, кто должен быть в курсе "товаров" исходя из закона Деметры, Creator'a, инкапсуляции ? мерчант или стратегия ?

можно я на 30 секунд вклинюсь с тупым вопросом, но меня переклинило и я жестко туплю, в контексте стратегии и пеймент-процессинга, кто должен быть в курсе "товаров" исходя из закона Деметры, Creator'a, инкапсуляции ? мерчант или стратегия ?

а почему пеймент процессингу не насрать на товары?

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

ну задача процессинга - взять деньнги и перевести их из точки "а" в точку "б". Почему он сие делает - его не волнует

почитать комменты, подумать, почему код хейтерам не понравился) мозг включить, например. На вскидку, можем сие предложить.

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

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

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

серьёзно?)

Так работает SaveRelationBehavior для Yii через __set. Можно инкапсулировать в коллекцию, если не нравится. Если хотите обсудить полноценные сущности, то это в цикле статей про Доменные Сущности.

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

в рамках мастер класса карл

да статья говно же. зачем меня к другой-то отсылать?

ERROR: S client not available

что бы я там тоже вляпался?

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

это ты еще блог Багуенко не читал

хех

ну просто нет что бы провести не масстер класс а курсы реабилитации

или сделать PR который позволяет не через __set а через прокси такое проворачивать

или портировать gii на ларавель с вуем

столько разные есть вариантов похоронить "это" и забыть как страшный сон

просто я вот не знаю от чего больше вреда

от yii или от подобных трюков которые обывателю не интуитивны

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

да статья говно же. зачем меня к другой-то отсылать?

Так там не одна статья, а пять. И четвёртая про косяки и костыли Doctrine. Может тоже понравится.

Так там не одна статья, а пять. И четвёртая про косяки и костыли Doctrine. Может тоже понравится.

вряд ли

Так там не одна статья, а пять. И четвёртая про косяки и костыли Doctrine. Может тоже понравится.

мне понравилась в одном из твоих видосов замена 4-х строчного foreach на записанный в одну строчку array filter с замыканием.

в видосе про ооп

я скорее всего вырвал из контекста - просто позабавило

> Doctrine ORM – это Collection-like система, эмулирующая коллекции при работе с сущностями. Рассмотрим, за счёт чего она это делает.

или портировать gii на ларавель с вуем

Ларавел с Eloquent со своими связями в плане агрегации ещё бесполезнее, так как просто присвоить связи и сохранить агрегат не умеет. И VO всё равно нужно также мапить вручную, как в AR.

Ох и срач

Ларавел с Eloquent со своими связями в плане агрегации ещё бесполезнее, так как просто присвоить связи и сохранить агрегат не умеет. И VO всё равно нужно также мапить вручную, как в AR.

не. если мы говорим про доменные сущности я выберу вариант с row data gateway

В твоей статье о том как доктрину юзать нашел следующее public function save(Employee $employee): void { $this->em->flush($employee); }

что невилирует какой либо профит от unit of work

как на счет запилить сервис рецензируемых обучающих статей?)

что невилирует какой либо профит от unit of work

Это сохраняет агрегат. Чем нивелирует?

критиканы

Это сохраняет агрегат. Чем нивелирует?

ты разбирался как работает UoW в ситуации когда ты коммитишь одну сущность?

и что в этом случае будет сохранен только корень агрегата а не стэйт всего агрегата

ну и еще что это deprecated фича которую выпилили для 3.0 (которая хорошо если через год зарелизиться потому все ок))

критиканы

и то правда... пойду своих статей попишу

и не буду их паблишить)

((

обнови домен с бложиком, нуу