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

Сейчас в мире облаков и модели плати за ресуры, каждая вот такая на первый взгляд мелоч выливается потом и суммируется во вполне конкретные расходы в виде долларов. Один полтзователь ну мелочь. А если тебе надо отправить сто тысяч сообщений? Теперь тебе надо сделать примерно 100 тыс * количетво вызовов методов билдера, клонирований

ты имел дело c highload? rps/latency?

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

Мой бенч показывает что вариант с мутабл быстрее в два раза чем вариант с имутабл

факт в том что время увеличилось в два раза. Причем это чисто ЦПУ время. А значит нагрузка на ЦПУ увеличилась в два раза. Я понимаю что не весь код проекта обклеен созданием месаджей и их отправкой. Но.. сейчас месадж, потом имутабл энтити, потом имутабл квери билдер, имутабл дто, имутабл коллекии. И это все копится. Просто странно с одной стороны у нас разрабы ядра, где парятся над тем как выровнять структуры в памяти чтобы быстрее кеш линии работали, разрабы компиляторов, которые десятилетиями оптимизируют всякие JIT компиляторы со спецулятивными оптимизациями, векторизациями и хвостовыми рекурсиями, где экономия ассемблерной инсрукции считается победой, а с другой стороны мы, которые берем и суем clone там где можно спокойно без него обойтись

Я как-то переписал один фронт проект на имутабл. Работает норм. Но какие же я там баги ловил. К примеру когда у тебя генерируется некое событие, и есть листенеры, каждый получает ссылку на имутабл объект. И если раньше я просто менял этот объект и все, то с имутабл каждый листенер получается создавал свою копию объекта, и другие листенеры ничего о ней не знали

Я как-то переписал один фронт проект на имутабл. Работает норм. Но какие же я там баги ловил. К примеру когда у тебя генерируется некое событие, и есть листенеры, каждый получает ссылку на имутабл объект. И если раньше я просто менял этот объект и все, то с имутабл каждый листенер получается создавал свою копию объекта, и другие листенеры ничего о ней не знали

факт в том что время увеличилось в два раза. Причем это чисто ЦПУ время. А значит нагрузка на ЦПУ увеличилась в два раза. Я понимаю что не весь код проекта обклеен созданием месаджей и их отправкой. Но.. сейчас месадж, потом имутабл энтити, потом имутабл квери билдер, имутабл дто, имутабл коллекии. И это все копится. Просто странно с одной стороны у нас разрабы ядра, где парятся над тем как выровнять структуры в памяти чтобы быстрее кеш линии работали, разрабы компиляторов, которые десятилетиями оптимизируют всякие JIT компиляторы со спецулятивными оптимизациями, векторизациями и хвостовыми рекурсиями, где экономия ассемблерной инсрукции считается победой, а с другой стороны мы, которые берем и суем clone там где можно спокойно без него обойтись

факт в том что время увеличилось в два раза. Причем это чисто ЦПУ время. А значит нагрузка на ЦПУ увеличилась в два раза. Я понимаю что не весь код проекта обклеен созданием месаджей и их отправкой. Но.. сейчас месадж, потом имутабл энтити, потом имутабл квери билдер, имутабл дто, имутабл коллекии. И это все копится. Просто странно с одной стороны у нас разрабы ядра, где парятся над тем как выровнять структуры в памяти чтобы быстрее кеш линии работали, разрабы компиляторов, которые десятилетиями оптимизируют всякие JIT компиляторы со спецулятивными оптимизациями, векторизациями и хвостовыми рекурсиями, где экономия ассемблерной инсрукции считается победой, а с другой стороны мы, которые берем и суем clone там где можно спокойно без него обойтись

Мне просто непонятно в каких случаях делать имутабл в каких не делать. Давайте все имутабл делать если это реально круто, получится хаскель в итоге.

Мне просто непонятно в каких случаях делать имутабл в каких не делать. Давайте все имутабл делать если это реально круто, получится хаскель в итоге.

Кто-то сталкивался с проблемой доктрины и постгрес когда нужно сделать default current_timestamp?

Товарищи, подскажите, пожалуйста, я верно понял, что доктрина не умеет в cascade persist для OneToMany? То есть, я использую api platform и хочу при изменении сущности передать массив связанных сущностей. Но их сохранение не работает. Но судя по гуглу, у некоторых все же работает

Умеет. Через апи платомформу такие кейсы были. Возможно у вас сеттеры не стоят или аддеры,ремоверы

хм, спасибо, проверю

Ну и плюс сами настройки платформы, надо группы номрализацией/денормализаций для коллекций настроить тоже. Были какие то заморочки

О, спасибо, наверное в этом дело, так как сеттерами порядок, они выполняются

Ну либо в главной сущности указать группы дочерней. Короче стратегии разные есть, но главное чтобы группа денормализации запроса была у обоих сущностей

Блин, чота фигня какая-то. Уже все варианты перепробовал. Группы из одной сущности в другую и наоборот и вообще убирал их. Не сохраняется...

Блин, чота фигня какая-то. Уже все варианты перепробовал. Группы из одной сущности в другую и наоборот и вообще убирал их. Не сохраняется...

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

Тут еще другая беда появилась, может дело в ней The total number of joined relations has exceeded the specified maximum. Raise the limit if necessary with the \"api_platform.eager_loading.max_joins\" Аттрибут #[MaxDepth(1)] не помогает

Это хз, еше вспомнил момент: вроде вторая сущность тоже должна быть ресурсом платформы. Но это не точно.

Она ресурс тоже... ... #[ApiResource( collectionOperations: [ 'get', 'post', ], itemOperations: [ 'get', 'put', 'delete' ], denormalizationContext: ['groups' => [Group::PROVIDER_ACCOUNT]], normalizationContext: ['groups' => [Group::PROVIDER_ACCOUNT]], )] ... class ProviderAccount { use EntityCreatedTrait; use EntityUpdatedTrait; #[ORM\Id] #[ORM\GeneratedValue] #[ORM\Column(type: Types::SMALLINT, options: ['unsigned' => true])] #[Groups([Group::PROVIDER_ACCOUNT])] private ?int $id = null; /** * @var Collection<MerchantAccount> */ #[ORM\OneToMany(mappedBy: 'providerAccount', targetEntity: MerchantAccount::class, cascade: ['persist'])] #[Groups([Group::PROVIDER_ACCOUNT])] private Collection $wallets; public function __construct() { $this->wallets = new ArrayCollection(); } public function getWallets(): Collection { return $this->wallets; } public function setWallets($wallets): self { $this->wallets = ($wallets instanceof Collection) ? $wallets : new ArrayCollection($wallets); return $this; } public function addWallet(MerchantAccount $wallet): self { if (!$this->wallets->contains($wallet)) { $this->wallets->add($wallet); } return $this; } public function removeWallet(MerchantAccount $wallet): self { if ($this->wallets->contains($wallet)) { $this->wallets->removeElement($wallet); } return $this; } } ... #[ApiResource( itemOperations: ['get', 'put'], subresourceOperations: [ 'merchant_orders_get_subresource' => [ 'method' => 'GET', 'path' => '/merchant_orders', 'controller' => 'App\Controller\Common\Api\Admin\Entity\MerchantOrder\GetAllActionClass' ] ], denormalizationContext: ['groups' => [Group::MERCHANT_ACCOUNT, Group::PROVIDER_ACCOUNT]], normalizationContext: ['groups' => [Group::MERCHANT_ACCOUNT, Group::PROVIDER_ACCOUNT], 'disable_type_enforcement' => true] )] ... class MerchantAccount { use EntityCreatedTrait; use EntityUpdatedTrait; #[ORM\Id] #[ORM\GeneratedValue] #[ORM\Column(type: Types::INTEGER)] #[Groups([Group::PROVIDER_ACCOUNT, Group::MERCHANT_ACCOUNT, Group::GATEWAY, Group::COMMISSION, Group::HOLD])] private ?int $id = null; #[ORM\ManyToOne(inversedBy: 'wallets', targetEntity: ProviderAccount::class)] #[Groups([Group::MERCHANT_ACCOUNT, Group::PROVIDER_ACCOUNT])] private ?ProviderAccount $providerAccount = null; ... public function getProviderAccount(): ?ProviderAccount { return $this->providerAccount; } public function setProviderAccount(?ProviderAccount $providerAccount): self { $this->providerAccount = $providerAccount; return $this; } ... }

Тут еще другая беда появилась, может дело в ней The total number of joined relations has exceeded the specified maximum. Raise the limit if necessary with the \"api_platform.eager_loading.max_joins\" Аттрибут #[MaxDepth(1)] не помогает

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

Но возможно кривота, и не факт что это что-то решает.

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

ну в случае DoctrineEnumBundle там varchar