Что отличает сущность вызванную Doctrine (методом find) от той которую мы сами создали?

Question

[Иван Антонов]

Написал скрипт переноса пользователей из старой БД, выглядит так:

$user = new User();
$user
    ->setId($u['id'])
    ->setEmail($u['user_email'])
    ->setUsername($u['login'])
; 
$em->persist($user);
$metadata = $em->getClassMetaData(get_class($user));
$metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);
$em->flush();

Работает исправно. Однако нужно добавить обновление пользователя, если он ранее был перенесен в базу.
Это не сложно сделать запросив запись методом find(); но хотелось бы удостовериться что у связки Doctrine+Symfony ничего не припасено для такого случая. Ведь тот же метод $em->persist(...); мы используем и для обновления записи.

Доп. вопрос: Если $em->flush(); вызывать не после каждого $em->persist(...);, а, например, через каждые 30 насколько изменится скорость переноса?

Answer 1

[Сергей Протько]

Ведь тот же метод $em->persist(...); мы используем и для обновления записи.

Вообще-то нет. По умолчанию persist используется для того, что бы добавить сущность в UnitOfWork. Вызывая его доктрина начинает разбираться, нам надо просто замерджить сущность в текущий UoW или добавить ее в очередь на вставку.

Вызывать persist при обновлении не нужно вовсе, можно обойтись merge, и только если у нас используется политика отслеживания изменений deferred-explicit, но это нужно в очень редких случаях. Например когда в рамках одного запроса мы должны загрузить из базы сотню-другую сущностей а обновить одну. В этом плане данная политика отслеживания изменений сильно ускоряет работу UoW, так как мы явно указываем за какими сущностями нам следить (сложность алгоритма UoW - O(N), так что чем меньше N тем быстрее работает). Единственное НО - это сильно усложняет работу с entity manager (по хорошему em должен быть только в репозитории), и в принципе ломает красивую концепцию persistence ignorance, так что использовать ее нужно только тогда, когда есть проблемы с производительностью UoW.

через каждые 30 насколько изменится скорость переноса?

Да, это ускорит работу. Единственное что, если вы занимаетесь вставкой большого количества объектов, имеет смысл после каждого flush делать clear, отчищать unit-of-work, поскольку вставленные сущности будут крутиться в нем, и после каждого flush их количество будет увеличиваться и скорость будет падать.

Comments

[Иван Антонов]

Спасибо, разобрался.
А так ли необходимо после каждого $em->persist($user); выполнять

$metadata = $em->getClassMetaData(get_class($user));
$metadata->setIdGeneratorType(\Doctrine\ORM\Mapping\ClassMetadata::GENERATOR_TYPE_NONE);

может достаточно одного раза для отмены автогенератора ID для каждого вызова $em->persist($user);?

[Алексей Скобкин]

Иван Антонов: Это уже ваши какие-то личные заморочки. Смотрите на свою логику. Если вам не нужно переопределять тип генератора, то я, например, не понимаю, зачем вы вообще это делаете.

[Иван Антонов]

Алексей Скобкин: что бы сохранить id записи из старой БД.

[Алексей Скобкин]

Иван Антонов: Если вы вручную задаёте id у записи, то почему бы вам это в маппинге не указать?

[Сергей Протько]

Алексей Скобкин: скорее всего потому что ему нужно это дело в рамках конкретной задачи, а затем уже должно быть автоматическая генерация.

Иван Антонов: вы тут правите метаданные, так что по идее достаточно один раз применить изменения.

[Алексей Скобкин]

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

[Иван Антонов]

Сергей Протько: а если я $em->persist($user); выполню перед заполнением метода, в БД будет вся информация? Так:

$user = new User();
$user->setId($u['id']);
$em->persist($user);
$user
    ->setEmail($u['user_email'])
    ->setUsername($u['login'])
;
$em->flush();

Просто не было возможности проверить.

[Сергей Протько]

Иван Антонов: да

[Иван Антонов]

Сергей Протько: спасибо

[Иван Антонов]

Сергей Протько: у меня несколько раз выводится ошибка

Notice: Undefined index: 00000000590c32c9000000004d239f5a in D:\xampp\htdocs\vendor\doctrine\orm\lib\Doctrine\ORM\UnitOfWork.php on line 2917

похоже что дело в $em->clear()

[Иван Антонов]

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

[Сергей Протько]

Иван Антонов: ну видимо он хочет заперсистить сущность которой нет в UoW. То есть тут уже надо смотреть как вы вообще что делаете.