Inconsistent behavior of Doctrine's entity listener - symfony

Question

I am creating a small app using Symfony 4 & Doctrine. There are users (User entities) and they are owning some kind of content called radio tables (RadioTable entity). Radio tables are containing radio stations (RadioStation entity). RadioStation.radioTableId is related to RadioTable (many to one) and RadioTable.ownerId is related to User (many to one).
Maybe I should notice that this is my first project with SF.
Entities are configured using annotations, this way:
<?php
namespace App\Entity;
/**
* #ORM\Entity(repositoryClass="App\Repository\UserRepository")
*/
class User implements UserInterface, \Serializable, EncoderAwareInterface
{
/**
* #ORM\OneToMany(targetEntity="App\Entity\RadioTable", mappedBy="owner", orphanRemoval=true)
*/
private $radioTables;
/**
* #ORM\Column(type="date")
*/
private $lastActivityDate;
}
// -----------------
namespace App\Entity;
/**
* #ORM\Entity(repositoryClass="App\Repository\RadioTableRepository")
* #ORM\EntityListeners({"App\EventListener\RadioTableListener"})
*/
class RadioTable
{
/**
* #ORM\ManyToOne(targetEntity="App\Entity\User", inversedBy="radioTables")
* #ORM\JoinColumn(nullable=false, onDelete="cascade")
*/
private $owner;
/**
* #ORM\Column(type="datetime")
*/
private $lastUpdateTime;
}
// -----------------
namespace App\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* #ORM\Entity(repositoryClass="App\Repository\RadioStationRepository")
* #ORM\EntityListeners({"App\EventListener\RadioStationListener"})
*/
class RadioStation
{
/**
* #ORM\ManyToOne(targetEntity="App\Entity\RadioTable")
* #ORM\JoinColumn(nullable=false, onDelete="cascade")
*/
private $radioTable;
}
I need to update $lastUpdateTime in a proper RadioTable entity when radio stations are added, removed or modified. Also, I need to update $lastActivityDate of the radio table owner (User class), when radio table is created, removed or updated. I am trying to achieve this by using entity listeners:
<?php
namespace App\EventListener;
class RadioStationListener
{
/**
* #PreFlush
* #PreRemove
*/
public function refreshLastUpdateTimeOfRadioTable(RadioStation $radioStation)
{
$radioStation->getRadioTable()->refreshLastUpdateTime();
}
}
// -----------------------------
namespace App\EventListener;
class RadioTableListener
{
/**
* #PreFlush
* #PreRemove
*/
public function refreshLastActivityDateOfUser(RadioTable $radioTable, PreFlushEventArgs $args)
{
$radioTable->getOwner()->refreshLastActivityDate();
/* hack */
$args->getEntityManager()->flush($radioTable->getOwner());
/* hack */
}
}
(In refresh*() methods I am just creating a new instance of \DateTime for proper entity field.)
I encountered the problem. When I tried to update/remove/create radio stations, RadioStation listener worked properly and related RadioTable class was successfully updated. But when I tried to update radio table, User class was updated but was not persisted to the database by Doctrine.
I was confused because the structure of the code in these entity listeners is very similar.
Partially I found the cause of the problem. It's obvious that only owner can modify its own radio tables and the user has to be logged in to modify them. I am using Security component from Symfony to support login-in mechanism.
When I temporarily hacked controller code to disable Security and tried to update the radio table as anonymous, RadioTable entity listener worked properly and User entity was successfully modified and persisted to database.
To fix the problem I need to manually talk with Doctrine's entity manager and call flush() with User entity as an argument (without argument I am doing endless loop). This line is marked by /* hack */ comment.
After this looong story, I want to ask the question: WHY I have to do it? WHY I have to manually call flush() for User object but only if Security component is used and the user is logged in?

Answer 1

I solved the problem.
Doctrine processes entities in a specified order. First, newly created entities (scheduled for INSERT) have precedence. Next, persisted entities (scheduled for UPDATE) are processed in the same order as they were fetched from the database. From inside entity listener, I am not able to predict or enforce the preferred order.
When I'm trying to update User's last activity date inside RadioTable's entity listener, changes made in User entity are not persisted. It's because in very early stage Security component loads my User object from DB and then Symfony prepares RadioTable object for the controller (by param converter for example).
To fix the issue I need to tell Doctrine to recalculate User entity changeset. Here is what I did.
I created small trait for my entity listeners:
<?php
namespace App\EventListener\EntityListener;
use Doctrine\Common\EventArgs;
trait EntityListenerTrait
{
// There is need to manually enforce update of associated entities,
// for example when User entity is modified inside RadioTable entity event.
// It's because associations are not tracked consistently inside Doctrine's events.
private function forceEntityUpdate(object $entity, EventArgs $args): void
{
$entityManager = $args->getEntityManager();
$entityManager->getUnitOfWork()->recomputeSingleEntityChangeSet(
$entityManager->getClassMetadata(get_class($entity)),
$entity
);
}
}
Inside entity listeners I am doing this:
<?php
namespace App\EventListener\EntityListener;
use App\Entity\RadioTable;
use Doctrine\Common\EventArgs;
use Doctrine\ORM\Mapping\PreFlush;
use Doctrine\ORM\Mapping\PreRemove;
class RadioTableListener
{
use EntityListenerTrait;
/**
* #PreFlush
* #PreRemove
*/
public function refreshLastActivityDateOfUser(RadioTable $radioTable, EventArgs $args): void
{
$user = $radioTable->getOwner();
$user->refreshLastActivityDate();
$this->forceEntityUpdate($user, $args);
}
}
There is another solution. It's possible to call $entityManager->flush($user) but it works properly only for UPDATEs, generates endless loop for INSERTs. To avoid endless loop it's possible to check $unitOfWork->isScheduledForInsert($radioTable).
This solution is worse because it generates additional transaction and SQL queries.