в документации есть про редринг контроллера из шаблона

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

или просто лэджер?

это да, но на сколько это будет правильно?

Что это такое?

знаешь как работают extra lazy ассоциации?

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

загугли) account ledger

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

вопрос правильно или не правильно - это надо вникать в контекст проблемы. В целом это неплохой способ снизить связанность

Если совсем не в моготу и хочется все считать сразу создай свой em с хранением в redis

нет

KISS

Нет

еще рас спрошу - ты знаешь как работают extra lazy ассоциации в доктрине?

Нет

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

Доброго дня снова! Скажите, а что вы использовали в качестве js клиента для отправки GraphQL запросов? Я использую библиотеки apollo-client и apollo-upload-client. Мне теперь нужно понять - это особенность этих библиотек или особенность Overblog GraphQL, а именно то, что, если отправлять мультипарт запрос с помощью apollo-upload-clien, то Overblog GraphQL не видит в запросе query и variables. Я залез в парсер запроса Overblog GraphQL - там он понимает, что может прийти мультипарт и ожидает его, но ожидает набор полей: query variables operationName В то время как Apollo посылает поля: operations map Судя по всему еще и формат хранимого полей различается, так как я уже пробовал жестко присвоить operations в query. Не помогло. Вот Request Payload, который шлется у меня на сервер: ------WebKitFormBoundaryfEqDQZLBkEmGBjvm Content-Disposition: form-data; name="operations" {"query":"mutation ($performer: PerformerInput!) {\n Performer(input: $performer)\n}\n","variables":{"performer":{"id":null,"firstName":"","lastName":"","patronymic":"asas","instagramLink":"","youtubeLink":"","insiderInfo":"","image":null}}} ------WebKitFormBoundaryfEqDQZLBkEmGBjvm Content-Disposition: form-data; name="map" {"0":["variables.performer.image"]} ------WebKitFormBoundaryfEqDQZLBkEmGBjvm Content-Disposition: form-data; name="0"; filename="blob" Content-Type: text/plain ------WebKitFormBoundaryfEqDQZLBkEmGBjvm-- Данные у меня все тестовые, так что не боюсь публиковать. От Overblog GraphQL отказаться уже не могу. Но JS клиент могу взять любой. Подскажите мне выход, если вы знаете уже готовый сценарий отправки файла на Overblog GraphQL сервер. Буду очень благодарен. Ведь у меня нет времени писать собственный парсер запросов

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

иногда это полезно

Но это нарушает принцип счистого кода. так ка увеличивает связанность

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

Есть проект, который пресдставляет из себя магазины, которые доступны на разных доменах, сайтов ограниченное кол-во основная идея что один и тот же товар продается в разных магазах. Не проблема вроде сделать сущность сайт, и запихнуть ее в базу, но товаров много а джойны и тем более join table я не люблю. Поэтому решено было хранить сайты в конфиге, и для этого был разработан сервис site. А для хранения типа сайта был сделан свой тип для доктрины котороер посути является array_type слегка расширенное, так вот это поле хранит сайт хендлы через запятую в базе, при загрузке срабатывал ивент доктрины в который был за инджектен сайт сервис который инициализирует array_collection и все сущности думают что это обычная аррай коллекция. Но возникла необходимость сделать каноникал для продуктов, и вот тогда было решение заинджектить сервис в сущность SITE потому что логика довольно мутная и именно был нужен сервис.

Он был за инжекжен прикрываясь Dependency Inversion принципом

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

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

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

SiteService был заинджекчен в entity Site

или другое - нафига вообще для урлов что-то в сущность пихать?

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

у тебя такой же взгляд?

Нет сущность продукта хранит только path конечный endpoint в зависимости от созданных адаптеров для сайтов разделов строится полный пункт и свой собственный router это все разруливает, дергая dynamicServiceFacade который резолвит конкретные адаптеры которые в конце концов дергают рендеры и процессоры

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

Да в 99% у меня сущность это контейнер + анотации + какие то мелкие методы типо получение полного имени и то это иногда вызывает множество проблем :) типо нет фамилии или еще что то

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