What distinguishes the entity called by Doctrine (by the find method) from the one we created ourselves?

Question

symfony

I wrote a script for transferring users from the old database, it looks like this:

$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();

Works properly. However, you need to add a user update if it was previously transferred to the database.
This is not hard to do by requesting a record using the find(); but I would like to make sure that the Doctrine + Symfony bundle does not have anything in store for such a case. After all, we use the same method $em->persist(...);to update the record.
Add. question : If you $em->flush();call not after each $em->persist(...);, but, for example, every 30, how much will the transfer speed change?

Answer 1

After all, the same $em->persist(...); we use and to update the record.

Actually, no. By default, persist is used to add the entity to the UnitOfWork. By calling it, the doctrine starts to understand, we just need to freeze the entity into the current UoW or add it to the insert queue.
You don’t need to call persist when updating, you can get by with merge, and only if we use the deferred-explicit change tracking policy, but this is needed in very rare cases. For example, when, within the framework of one request, we must download a hundred or two entities from the database and update one. In this regard, this change tracking policy greatly speeds up the work of UoW, since we explicitly indicate which entities we should monitor (the complexity of the UoW algorithm is O (N), so the smaller N the faster it works). The only BUT is that it greatly complicates the work with the entity manager (for good, em should only be in the repository), and basically breaks the beautiful concept of persistence ignorance, so you should use it only when there are problems with UoW performance.
Yes, it will speed things up. The only thing is that if you are inserting a large number of objects, it makes sense to do clear after each flush, clean up the unit-of-work, since the inserted entities will spin in it, and after each flush their number will increase and the speed will drop.