How to defeat Undefined index in UnitOfWork when saving inside postRemove?

Question

symfony

Newbie on the subject. I write logs to a spreadsheet. When deleting an entity in the postRemove listner, I try to do this

$this->entityManager->persist($logRecord);
 $this->entityManager->flush();

Most of the time it works without errors. But sometimes I get an error (perhaps when dealing with related entities)

Symfony\Component\Debug\Exception\ContextErrorException: Notice: Undefined index: 0000000045c434420000000058164e1f in /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php:2917 Stack trace: #0 /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Collection/ManyToManyPersister.php(522): Doctrine\ORM\UnitOfWork->getEntityIdentifier(Object(VimBundle\Entity\ViewArea)) 

#1 /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Collection/ManyToManyPersister.php(452): Doctrine\ORM\Persisters\Collection\ManyToManyPersister->collectJoinTableColumnParameters(Object(Doctrine\ORM\PersistentCollection), Object(VimBundle\Entity\ViewArea)) 

#2 /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/Collection/ManyToManyPersister.php(71): Doctrine\ORM\Persisters\Collection\ManyToManyPersister->getDeleteRowSQLParameters(Object(Doctrine\ORM\PersistentCollection), Object(VimBundle\Entity\ViewArea)) 

#3 /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php(400): Doctrine\ORM\Persisters\Collection\ManyToManyPersister->update(Object(Doctrine\ORM\PersistentCollection)) 

#4 /var/www/vim/back/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php(356): Doctrine\ORM\UnitOfWork->commit(NULL) 

#5 /var/www/vim/back/var/cache/dev/ContainerBahllwd/EntityManager_9a5be93.php(170): Doctrine\ORM\EntityManager->flush(NULL) 

#6 /var/www/vim/back/src/VimBundle/EventListener/DoctrineEventListener/ChangesLogListener.php(447): EntityManager_9a5be93->flush()

Drowned in the dock. ))
Tell me where to dig.
Thanks

Answer 1

The documentation for the event postRemoveexplicitly states that this event is called inside the flush(). So by calling $this->entityManager->flush()internally postRemove, you are actually spawning a potentially infinite loop, so "Undefined index" is really the least of your problems :)
It would be more correct to organize the work something like this:

1. Move the logic for saving changes to a separate service
   
2. Wrap the process of saving changes in a transaction
   
3. In lifecycle methods, do not try to write data immediately, but instead collect information for writing to a certain collection, in the simplest case, an array
   
4. After the main flush, check the contents of the collection and, if there is something there, form a separate set of changes in entities and do a new flush.
   
5. If everything went well - commit transactions at the end
   

Answer 2

Here it is necessary to look at structure of tables. Maybe I forgot where to write inversedBy (I had this), maybe I messed up with indexes. Check carefully all the moments where links and collections are used.