с новыми плюшками

в целом из важных вещей это argument resolvers которые вообще в 3.2 или даже 3.1 есть

param converter есть же

param converter есть же

да, с этим и жил на 3.0)

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

и как-то печально стало

из-за отсутствия нормальной работы с json body

из-за отсутствия нормальной работы с json body

?

нет варианта из коробки

нужно свой собирать

что свой собирать?

ты ро то что Request тебе максимум даст строку а дальше делай что хочешь?

да

валидацию конвертацию и тд

ну да, это так себе.... но аргумент ресолверы же)

ну эт и есть собирать самому )

ну а что бы ты хотел?)

JsonRequest?

с поддержкой json path?

а вот хз даже

поэтому и плохо

нет какого-то варианта из коробки

шоб удобно)

не хочу лишний раз думаьб

нет какого-то варианта из коробки

у всех разные запросы - потому этого нет из коробки))

http://udidahan.com/2016/02/19/ask-udi-two-services-operating-on-the-same-entity/

вот еще неплохая статья с отсылками на другие статьи)

для тех у кого не круд)

vimeo на пхп?

Ребят, привет. Я новичок, пожалуйста подскажите мне: Делаю массовое заполнение данных (Insert или Update), использую доктрину, но скорость прям очень и очень медленная, где-то 8 тысяч записей за 40-60 минут. Как делаю и SQL дамп https://pastebin.com/raw/yTmZRiWZ что я делаю не правильно?

Ребят, привет. Я новичок, пожалуйста подскажите мне: Делаю массовое заполнение данных (Insert или Update), использую доктрину, но скорость прям очень и очень медленная, где-то 8 тысяч записей за 40-60 минут. Как делаю и SQL дамп https://pastebin.com/raw/yTmZRiWZ что я делаю не правильно?

не читаешь доку

@fes0r можешь направить на путь истенный? За образец брал это http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/batch-processing.html

ну то есть проблема у тебя 90% что с UoW

и даже тот факт что у тебя там итерации по 500 штук

не говорит сколько объектов крутится в UoW

более того, может быть узкое место вообще твой этот validate

+ если ты делаешь clear, есть часто повторяющиеся запросы на SELECT, нет secondary level кэша, может быть тоже медленно

(я думаю даже что ты по этой причине поставил 500 а не 50)

Прости пожалуйста, UoW - много объектов? validate - проверяет что бы оба значения в объекте было true. clear - получается вообще тут бесполезен? Так как хранит только select?

Прости пожалуйста, UoW - много объектов? validate - проверяет что бы оба значения в объекте было true. clear - получается вообще тут бесполезен? Так как хранит только select?

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

> clear - получается вообще тут бесполезен? Так как хранит только select? нет, UoW хранит все. Если ты сделал селект 1000-чи сущностей на 500 итераций у тебя в UoW будет 1500 сущностей

или больше если у тебя сущности которые ты персистишь включают в себя еще какие-то

(можно посчитать достав identity map из uow, шутки ради можешь это сделать перед clear)

еще - можно попробовать завернуть все это в транзакцию сверху

хотя ты и так делаешь 1 флаш

Покажи свой батч процессинг

Я с ним извращался как угодно уже ))

Покажи свой батч процессинг

процессинг он кинул - там с виду все ок (только количество итераций дофига)

Хз, там только внутрення часть. Как он делает по 500 записей?

Он делает только один clear

Покажи все плис

У меня 100к экселя пишется оч быстро, за итерацию 6 энтитей связывается

полностью вся функция, задача взять существующие записи новостей и составить новую таблицу если адрес новости отдаёт ответ отличный от 200 https://pastebin.com/raw/RjpnS9tc

> $entities = $this->em ->getRepository(News::class) ->getOnlyActiveNews($limit,$offset,[ NewsBad::class, 'newsBad', 'WITH', 'newsBad.news = n.id' ]);

сколько у тебя там сущностей?

clear нету

около ста тысяч

.....

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

13.2.2. Iterating results

в доке

и clear

и делай clear каждые 100 итераций например

100 -150 оптимально

около ста тысяч

А ты смотрел профайлер ?

ERROR: S client not available

Там же все написано будет ))

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

->getOnlyActiveNews($limit,$offset,[ NewsBad::class, 'newsBad', 'WITH', 'newsBad.news = n.id' ]);

а вот это что?

что-то мне подсказывает что это one-to-many или many-to-many

https://pastebin.com/raw/hr9VqCxQ

ой

я вынес просто запрос в репозиторий, что бы использовать повторно

что такое?

открой про батч селект

ты ж понимаешь что offset limit не спасут если ты не чистишь юнит оф ворк?)

ну вот ты обработал 100 сущностей и надо их почистить

я про этот метод

checkingBadLinks

В конец обратно добивить clear?

крч смотри. тебе надо итератор + запись по 100 и после каждых 100 ты чистишь uow

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

1. выбрать только айдишки

2. потом по айдишкам доставать по 10 штук твоих сущностей

судя по всему там еще релейшенов дохера

крч смотри. тебе надо итератор + запись по 100 и после каждых 100 ты чистишь uow

https://pastebin.com/raw/ADri4bHH так?

Да мне связи нужно для обработки

около такого

но насчет айди тебе правильно говорят

и кстати глянь что такое $em->getReference()

если знаешь айди - не надо выбирать всю сущность

крч возьми на вооружение 1) итератор для выборки 2) получить id вместо обьекта и юзнуть getReference 3) каждых 100-150 итераций clear flush 4) заверни все в try catch и в случае фейла делай ролбэк

не очень понимаю, причём тут clear, если первая итерация занимает c cохранением 40 секунд, без сохранения (persist and flush) - 3 секунды ?

не очень понимаю, причём тут clear, если первая итерация занимает c cохранением 40 секунд, без сохранения (persist and flush) - 3 секунды ?

без сохранения ты ничего не делаешь

с сохранением - делаешь)) разберись что такое unit of work

то есть сохранять 100 записей 37 секунд норм?

грубо говоря, когда ты делаешь persist ты говоришь UoW следить за сущностью