я даже не слежу что там в своп летит, возможно м2 дает знать, я даже хз

Вот поднял проект, ну и еще хром с 10 вкладками(что мало). Но правда там штук 20 воркеров крутится, если уронить - будет естественно меньше

Опять же если какая нить инмемори и надо потестить что то неплохо - тоже можно встрять

Но это скорее редкие кейсы

Воркера уронил 14.7 занято :)

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

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

Ну так я уронил - стало 14.7 =)

Что впритык к 16

Другое дело что при 16 будет выгружать более резво я думаю

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

Неиспользуемое

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

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

ага запустил весь проект локально в кубере )

ага запустил весь проект локально в кубере )

=) ну я не про крайности )

опять же своп = оперативка * 2, ставишь м2 и пофиг

опять же своп = оперативка * 2, ставишь м2 и пофиг

Ну да, можно за счет ssd выехать, но оно все же помедленнее будет и ssd сажать

ну ты его сильно не посадишь, если постоянно не перезапускажешь контейнеры

Ну короче имхо, 16 да, еще более комфортно, но если есть кэш - лучше 32, поддерживаю

ну ты его сильно не посадишь, если постоянно не перезапускажешь контейнеры

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

чтение пофиг

чтение пофиг

Ну наверное да.

Привет! В сущности есть поле json. C фронта прилетает массив объектов, если их тупо смаппить в DTO, то в таблицу пишется корректно, а если в DTO использовать поле, как массив другой DTO, то в таблицу кладется пустой массив объектов [{},{},{},{},{},{},{},{},{},{},{}] как надо дополнительно настроить doctrine, чтобы не было так

ничего не понял)

json - это же тупо stdclass, скаляры и массивы

DTO он хавает просто потому что так получается

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

ничего не понял )

так что путь следующий: 1) или из DTO сделать VO, добавив jsonSerialize 2) или написать свой тип для доктрины, где будет использовать serializer, который и будет нормализовывать значения

или самый нормальный и правильный вариант - отправлять в сущность нормализованные объекты сущности, т.к. они даже не рядом с данными/dto из запросов и не имеют к ним никакого отношения

есть же вроде расширения, которые это делают

ExampleDTO { /**@var FooDTO[] $fields */ private array $fields; так не работает

ExampleDTO { private array $fields; а так работает

по идее свой тип, хорошая идея

оно и так и так не должно

ExampleDTO { private array $fields; а так работает

Лучше всегда использовать явное поведение

это просто багло, что у тебя второй вариант пашет

Лучше всегда использовать явное поведение

не совсем понял

не совсем понял

Лучше явно сериализоватб объект и отправить в бд

Лучше явно сериализоватб объект и отправить в бд

или использовать VO)

у нас же орм

А не надеяться на не явные штуки, которые это сами сделают

Не явных штук в ларе много. И к чему это их привело 😄

Лучше явно сериализоватб объект и отправить в бд

те нужно сначала сериализовать и положить в базу, получается свой тип запилить или можно перед записью сделать?

Не явных штук в ларе много. И к чему это их привело 😄

не знаю, не пробовал лару

final readonly class ExampleValueObject implements \JsonSerializable { public function __construct( /** * @var iterable<array-key, FooValueObject> */ public iterable $fields, ) {} public function jsonSerialize(): array { return [ 'fields' => \iterator_to_array($this->fields, false), ]; } } final readonly class FooValueObject implements \JsonSerializable { public function __construct( public string $foo, public string $bar, ) {} public function jsonSerialize(): array { return \get_object_vars($this); } }

ну хотя бы

хотя тоже не очень из-за прибития гвоздями JsonSerializable но т.к. это VO, то можно

те нужно сначала сериализовать и положить в базу, получается свой тип запилить или можно перед записью сделать?

Смотря какой там объект у тебя, насколько сложный. Пример выше как вариант

там просто массив объектов и объекты простые, без вложенности

а так-то лучше свой тип сделать для этого json

а внутри него уже руками положить в VO при получении и разложить обратно в ассоциативный при сохранении явно

Спасибо

но вообще, в принципе json только для одного норм, имхо - делать что-то вроде EAV) Где можно в поле value сохранять значения разных типов, а не под каждый тип своё поле фигачить))))

больше ни для чего json нафиг не нужен

но вообще, в принципе json только для одного норм, имхо - делать что-то вроде EAV) Где можно в поле value сохранять значения разных типов, а не под каждый тип своё поле фигачить))))

мой случай

ну вот я только там для значений json и использовал

а внутри него уже руками положить в VO при получении и разложить обратно в ассоциативный при сохранении явно

в нее dto маппить получается

ну вот я только там для значений json и использовал

типа: // Дискриминатор мапа по type abstract class AttributeValue { // json protected mixed $value; // many2one public Attribute $attribute; } final class IntAttributeValue extends AttributeValue { public function __construct(int $value, ...) { $this->value = $value; } }

в нее dto маппить получается

VO - это DTO с поведением)

#[MapRequestPayload] UserVO $userVO поймет?

MapRequestPayload - это слой представления вообще)

а пользовательские данные никакого отношения к энтитям и бд не имеют

а пользовательские данные никакого отношения к энтитям и бд не имеют

Ну такое, имеет ли VO отношение к энтити? имеет. Может ли представление сразу создать VO из реквеста? Почему бы и нет.

Ну такое, имеет ли VO отношение к энтити? имеет. Может ли представление сразу создать VO из реквеста? Почему бы и нет.

нет же)

ну.... хотя...

нет же)

Ну а почему бы и нет? Что случится если будет сразу емейл VO?

Ну а почему бы и нет? Что случится если будет сразу емейл VO?

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

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

ну я понимаю, конечно, что можно забить болт

но проблем там ппц

но проблем там ппц

Каких?

не, если из одного поля VO, то вполне норм ещё

ну т.е. не норм, конечно

но терпимо

)))))

кроме валидации - никаких проблем

Ну короче надо просто прогать и всё =) Если не мешает - значит норм

это сейчас не мешает

кроме валидации - никаких проблем

Валидация вообще по хорошему должна быть не на ДТО, раз уж на то пошло, а на реквест - которая кучка данных

Валидация вообще по хорошему должна быть не на ДТО, раз уж на то пошло, а на реквест - которая кучка данных

ну так на DTO тоже, всякие инварианты

non empty в частности