Как победить Undefined index в UnitOfWork при сохранении внутри postRemove?

Question

[coderisimo]

В предмете новичок. Пишу логи в таблицу. При удалении сущности в листнере postRemove пытаюсь сделать так

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

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

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

В доке утонул. ))
Подскажите, куда копать.
Спасибо

Answer 1

[Flying]

В документации к событию postRemove прямо указано что это событие вызывается внутри метода flush(). Таким образом вызывая $this->entityManager->flush() внутри postRemove вы, фактически порождаете потенциально бесконечный цикл, поэтому "Undefined index" на самом деле - наименьшая из ваших проблем :)

Более корректно будет организовать работу примерно следующим образом:

1. Вынести логику сохранения изменений в отдельный сервис
   
2. Обернуть процесс сохранения изменений в транзакцию
   
3. В lifecycle методах не пытаться писать данные сразу, а вместо этого собирать информацию для записи в некую коллекцию, в простейшем случае - массив
   
4. После основного flush'а проверять содержимое коллекции и если там что-то есть - формировать отдельный набор изменений в entities и делать новый flush.
   
5. Если всё прошло хорошо - в конце делать commit транзакции
   

Comments

[coderisimo]

Большое спасибо за развернутый ответ!

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

К сожалению, не порождаю. Это было бы здорово, если бы было так просто )))

/**
     * @param LifecycleEventArgs $args
     */
    public function postRemove(LifecycleEventArgs $args)
    {
    
        try {
            /** @var Entity $entity */
            $entity = $args->getObject();
            if ($this->skipToHandle($entity)) {
// метод выше проверяет, что обрабатываемая сущность не наш ЛОГ
// соответственно, вызывая для лога $this->entityManager->flush()
// мы не запускаем бесконечный цикл
                return;
            }

Можете подсказать где

После основного flush'а проверять содержимое коллекции...

? postFlush мне не помог.

[BoShurik]

После основного flush'а проверять содержимое коллекции...

Для логов можно использовать эвенты symfony:
https://symfony.com/doc/current/components/http_ke...
https://symfony.com/doc/current/components/console...

[coderisimo]

Т.е
1) заводим сервис.
2) Собираем данные в эвентах доктрины,
3) а затем в kernel.terminate сохраняем все в таблицу с логами?

[Flying]

coderisimo, postFlush и не поможет т.к., опять же, в документации прямо написано что нельзя из postFlush вызывать flush(). Я имел в виду что-то подобное (пишу по памяти, так что могу в деталях ошибиться):

function flush() {
    $em = $this->entityManager;
    $logs = new Collection();
    $em->beginTransaction();
    try {
        $em->flush();
        if (!$logs->empty()) {
            // Добавляем собранные данные в базу
            $em->flush();
        }
        $em->commit();
    } catch (\Throwable $e) {
        // Обрабатываем исключение
        $em->rollback();
    }
}

Ну и да, подход предложенный BoShurik по факту ещё лучше т.к. не нагружает приложение до момента отдачи ответа клиенту.

[coderisimo]

Flying, По факту гуглится самая разнообразная информация.
Например - https://stackoverflow.com/questions/16904462/addin...

Спасибо за мысли.

[Flying]

coderisimo, Там вопрос и ответ 2013-го года, это довольно давно :) Гораздо выгоднее доверять официальной документации Doctrine, вот конкретное место.

[coderisimo]

Flying, это я у же до дыр зачитал )))

Answer 2

[sl0]

Тут надо смотреть на структуру таблиц. Может забыл где прописать inversedBy (было у меня такое), может c индексами напутано. Проверь внимательно все моменты, где используются связи и коллекции.

Comments

[coderisimo]

Спасибо. Общая идея ясна. Поищу!

[coderisimo]

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