спасбо всем, получилось

всем привет, вылил сайт на хостин правда там РНР чуток ниже (5,4) и появилась ошибка Parse error: syntax error, unexpected 'class' (T_CLASS), expecting variable (T_VARIABLE) or '$' содержимое строку на которую указывает ошибка ->add('deadline', DateTimeType::class, array( как эту ошибку можно устранить?

жаль такое слышать)

Доброе утро, тем кто не спит

Есть база данных (старая). Нужно конвертировать в новую. Сделал костыль через fixture

Простые записи - обрабатываются легко. а там где джойны есть - слегка пртоможенно... То есть, есть таблица - категории, ключевые слова - с ними рпоблем нет, создается reference и потом, в таблицу материалы - уже задаются в зависимости от референса (поля @ORM/ManyToMany/OneToMany/ManyToOne в зависимости от ситуации) . ТАк вот последняя эта таблица - обрабатывается оооооочень долго. Хоть и порционно (каждые 1000 записей flush, clear). У кого есть еще какие идеи / опыт / итд, как ускорить этот процесссс

Почему dump((array)$entity) выдает такую срань http://prntscr.com/dyq483 а не нормальный массив?

Все, понял

Ну что, есть может у кого мысли - как 20к+ записей по-быстрому вставить :) Есть поля,связанные с другими сущностями @ManyToMany. Так что после ->flush(), ->clear() - очень долгая обработка

SQL batch insert

Ну что, есть может у кого мысли - как 20к+ записей по-быстрому вставить :) Есть поля,связанные с другими сущностями @ManyToMany. Так что после ->flush(), ->clear() - очень долгая обработка

Убрать доктрину из процесса, например.

быстрее не придумать

Вариант без clear работает быстро в принципе, но память съедает ацки

Вариант без clear работает быстро в принципе, но память съедает ацки

зачем тебе для миграции структуры базы ORM?

у меня не миграция

у меня трансформация из одной базы - в другую

Ты сказал, что со старой базы на новую мигрируешь.

миграция данных с одной структуры на другую

а ну это да

ну так жахни кучку SQL

Ну вот и как бы зачем тебе ORM.

да и вообще

это одноразовая операция?

ну то есть самый быстрый - SQLы чистые

Да

ну тогда без clear сделай

и выдели пару гигов памяти

или делай с clear

и жди

20К не так много

с clear - 18 часов ~ получается

Если тебе не нужны какие-нибудь фичи ORM типа Lifecycle Callbacks или ивентов доктрины или ещё чего-то - особого смысла в доктрине при импорте данных нет.

Если бы ночью вчера запустил - то можно было бы

с clear - 18 часов ~ получается

это ж как плохо то все

Ну вот не знаю, как-то так... Может конечно еще где-то косячу

это получается что всего тысяча записей в ЧАС

Кстати, зачем мигрировать в фикстуре - тоже вопрос, конечно.

это ж какая там стремная структура базы

Кстати, зачем мигрировать в фикстуре - тоже вопрос, конечно.

я тож не понял

Первые три тысячи - за 15 минут :) а дальше начинается тупняк

Эстонская база?

банальный insert с вложенным SELECT

Кстати, зачем мигрировать в фикстуре - тоже вопрос, конечно.

Поэтому и костыль

Первые три тысячи - за 15 минут :) а дальше начинается тупняк

тупняк начинается потому что PHP и сборка мусора.

clear должен спасать

clear() можно делать реже. Если ты в память не упираешься, то чего дёргать-то его, если это разовая операция?

Ну и если identity map не перегружен, конечно, уже.

раз в пару тысяч записей делай clear

Я примерно так и делаю на проектах, где надо большие объёмы данных именно через доктрину пропускать. Раз в несколько тысяч итераций.

Если clear убирать - то получается нужно уже cascade={"persist"} указывать, таких полей 4

Если clear убирать - то получается нужно уже cascade={"persist"} указывать, таких полей 4

эм.... ну так это норм

иначе повторюсь

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

и только страдаешь

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

все остальное - ORM не нужна

SQL/DQL

В общем, спасибо, сейчас подумаю еще и либо памяти выделю, либо пойду на DQL/SQL перепишу

проще памяти докинуть

зачем тратить время и оптимизировать одноразовую операцию

Спасибо. Выделю память, пойду смотреть на то, во что превратиться

Спасибо. Выделю память, пойду смотреть на то, во что превратиться

а вот это делал? я помню мне когда-то давно помогло

$em->getConnection()->getConfiguration()->setSQLLogger(null);

Так и не понял для чего multiple-transaction нужен в фикстурах. Думал что он делает один множественный инсерт

хотя это было много лет назад

$em->getConnection()->getConfiguration()->setSQLLogger(null);

--no-debug вроде выключает это

но не делал

ERROR: S client not available

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

Хм

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

Надо попробовать

максимально все облегчить, что можно

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

потому что по дефолту юзается cross-finger handler монолога который пишет сначала в буфер и надо периодически ему тоже флаш делатью

многие любители пописать на симфони демонов на это напарываются

потому что по дефолту юзается cross-finger handler монолога который пишет сначала в буфер и надо периодически ему тоже флаш делатью

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

Хм

Память перестала утекать

400мб хватает , и почти закончилась процедура

это без логера?

Да и с ноу-дебаг

повторюсь, потому что флашить надо монолог

Так что полезным оказалось. Благодарю!

что бы он буферы не переполнял

повторюсь, потому что флашить надо монолог

Или отключать ) как флашить надо тоже почитать

https://github.com/mac-cain13/daemonizable-command

рекомендую

там есть раздел про память

Благодарю

За час все раскидалось. Всем, кто помогал советами и мыслями, большое спасибо1

https://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb-bulk-data-loading.html

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

:) doctrine так умеет делать?

вродь оно http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/transactions-and-concurrency.html#approach-2-explicitly

и http://stackoverflow.com/a/9710383/3204244

Спасибо. Посмотрю

Вопрос, те кто юзают DoctrineFixtureBundle... никто не загонялся по конфигурируемым фикстурам?

ну мол... что-то типа

$this->loadFixtures([ (new ProductChatFixtures())->withHiddenChats() ]);

или лучше так не делать?)