got another Symfony2 issue, more specifically postPersist does not seem to execute after the persist.
In my controller I have a createAction (removed some code)
public function createAction(Request $request)
{
try {
$em = $this->getDoctrine()->getManager();
$alert = new AvailabilityAlert();
$alert->setLastUpdated();
$alert->setIsDeleted(0);
$alert->setAlertStatus('Active');
$em->persist($alert);
$em->flush();
return new JsonResponse('Success');
}catch (Exception $e) {
}
}
To this, I have an EventListener in place
<?php
namespace Nick\AlertBundle\EventListener;
use Doctrine\ORM\Event\LifecycleEventArgs;
use Nick\AlertBundle\Entity\AvailabilityAlert;
use Nick\AlertBundle\Service\UapiService;
class AvailabilityAlertListener
{
protected $api_service;
public function __construct(UapiService $api_service)
{
$this->api_service = $api_service;
}
public function postPersist(LifecycleEventArgs $args)
{
$entity = $args->getEntity();
if ($entity instanceof AvailabilityAlert) {
$this->api_service->addFlightsAction($entity);
}
}
}
From what I understand, this postPersist should execute after the AvailabilityAlert is persisted to the database?
Inside my listener I call a function addFlightsAction. This function does a database query. This query essentially selects the data I need where the id is equal to the id I pass it (the one created by new AvailabilityAlert() ). To get this id, I use $entity->getId().
I have outputted the id and it is correct. However, when I output the result from the database query I receive an empty array. If however in my database query I do
$id = $entity->getId();
... query code
->setParameter('id', $id-1)
So take 1 away from the current id, the query returns the data from the last alert I inserted. So this tells me that when I give it the alert id of the current alert and I get no data from this, the current alert has not been persisted to the database at the time this is happening.
Is there any way to resolve this?
p.s. My service
doctrine.availability_alert_listener:
class: Nick\AlertBundle\EventListener\AvailabilityAlertListener
arguments: [#alert_bundle.api_service]
tags:
- { name: doctrine.event_listener, event: postPersist }
Thanks
Since the inserts are happening in a transaction, which hasn't been committed yet, the records that you have just written may not yet be available to read back in.
If all the data you need to do the call to addFlightsAction is in the entity, you have the data available there. Alternatively, you may be able to gather the rest of the data that has just been written via $args->getEntityManager()->getUnitOfWork();
Otherwise, you could always just run the addFlight code after the flush, when the transaction has been committed.
Fire your query in the postFlush event instead of the postPersist event, this should let you do $id-1 as you described above.
Keep in mind that postFlush args are a instance of PostFlushEventArgs, not LifecycleEventArgs
Related
I am working on an app in Symfony 3 using Doctrine.
Whenever I persist or update a specific entity, I need to query for a subset of these entities (same class) and update a property for each.
Currently I have an entity listener class with postPersist() and postUpdate() handlers which call a function performing the aforementioned behaviour.
However, I am finding that when persisting changes for these other entities, it is triggering events leading to additional lifecycle callbacks to postUpdate() on the same listener (as somewhat expected, but undesired).
I wanted to ask if anyone would know of a way to suppress these additional events or possibly have any ideas on alternative solutions to this scenario.
Update: Providing sample code to help illustrate the issue
// Subscribed Entity Listener for Foo
class FooListener
{
...
public function postPersist(Foo $foo, LifecycleEventArgs $event)
{
...
$this->updateFlaggedFoos($event);
}
public function postUpdate(Foo $foo, LifecycleEventArgs $event)
{
...
$this->updateFlaggedFoos($event);
}
private function updateFlaggedFoos(LifecycleEventArgs $event)
{
$user = $this->tokenStorage->getToken()->getUser();
$entityManager = $event->getEntityManager();
$userFoos = $entityManager->getRepository('MyApp:Foo')->getUserFoos($user);
foreach($userFoos as $foo) {
if ($this->determineIfFlagValueNeedsToChange($foo)) {
$foo->setFlagValue( ! $foo->isFlagged());
$entityManager->persist($foo); // Causes postUpdate() to be called again.
}
}
}
...
}
In my symfony application i've got my event_subscriber
CoreBundle\EventSubscriber\CloseIssueSubscriber:
tags:
- { name: doctrine_mongodb.odm.event_subscriber, connection: default }
My subscriber simply listen to postPersist and postUpdate events:
public function getSubscribedEvents()
{
return array(
'postPersist',
'postUpdate',
);
}
public function postPersist(LifecycleEventArgs $args)
{
$this->index($args);
}
public function postUpdate(LifecycleEventArgs $args)
{
$this->index($args);
}
In my index function what I need to do is to get if certain field has changed in particular the issue.status field.
public function index(LifecycleEventArgs $args)
{
$document = $args->getEntity();
$originalData = $uow->getOriginalDocumentData($document);
$originalStatus = $originalData && !empty($originalData['issue']) ? $originalData['issue']->getStatus() : null;
var_dump($originalStatus);
var_dump($document->getIssue()->getStatus());die;
}
In my test what I do is change the issue.status field so I expect to receive 2 different values from the var_dump but instead I got the last status from both.
My document is simply something like that:
class Payload
{
/**
* #ODM\Id
*/
private $id;
/**
* #ODM\EmbedOne(targetDocument="CoreBundle\Document\Issue\Issue")
* #Type("CoreBundle\Document\Issue\Issue")
*/
protected $issue;
}
In the embedded issue document status is simply a text field.
I've also try to use the changeset:
$changeset = $uow->getDocumentChangeSet($document);
foreach ($changeset as $fieldName => $change) {
list($old, $new) = $change;
}
var_dump($old->getStatus());
var_dump($new->getStatus());
Also this two var_dumps returns the same status.
By the time of postUpdate changes in the document are already done so originalDocumentData is adjusted and ready for new calculations. Instead you should hook into preUpdate event and use $uow->getDocumentChangeSet($document); there.
I guess that you want to run index once changes have been written to the database, so on preUpdate you can accumulate changes in the listener and additionally hook into postFlush event to re-index documents.
I found the solution to my problem.
What malarzm said in the other answer is correct but not the solution to my problem.
I suppose that I get only one postUpdate/preUpdate postPersist/prePersist just for the Document (Payload) instead I notice that it get called event for the embedded document (don't know why doctrine consider it a persist).
So the main problem is that I'm waiting for a Payload object instead I have to wait for a Issue object.
In other hands I was unable to use the getOriginalDocumentData work right even in the postUpdate and in the preUpdate so I have to use the getDocumentChangeSet().
I have two entities , user and store, they have a many-to-one relationship, before I create a user, I have to make sure a store is existed, it is not allowed to create a store while creating a user ,that means cascade={"persist"} can't be used.
Store class
public function addUser(User $user)
{
if (!$this->users->contains($user))
{
$this->users->add($user);
$user->setStore($this);
}
return $this;
}
before I create a user , I am pretty sure that a store is already existed.these code below is the way I used to create user
$store= $this->get('vmsp.store_provider')->getCurrentStore();
$store->addUser($user);
$userManager->updateUser($user);
code in updateUser method is not special:
$this->entityManager->persist($user);
$this->entityManager->flush();
code in getCurrentStore method:
public function getCurrentStore($throwException=true)
{
if (isset(self::$store)) {
return self::$store;
}
$request = $this->requestStack->getCurrentRequest();
$storeId = $request->attributes->get('storeId', '');
$store = $this->entityRepository->find($storeId);
if ($store === NULL&&$throwException) {
throw new NotFoundHttpException('Store is not found');
}
self::$store = $store;
return $store;
}
this gives me a error:
A new entity was found through the relationship
'VMSP\UserBundle\Entity\User#store' that was not configured to cascade
persist operations for entity: ~ #1. To solve this issue: Either
explicitly call EntityManager#persist() on this unknown entity or
configure cascade persist this association in the mapping for example
#ManyToOne(..,cascade={"persist"})
thing is getting very interesting, why does a existed store become new entity? why does doctrine think that existed store entity as a new entity?
It seems like your Store-entity is detached from the EntityManager somehow. I can't really see where it happens. Finding that out will probably take a few debugging sessions by you.
A quick fix might be to merge the user's store back into the EntityManager using EntityManager::merge($entity), e.g. in your updateUser-method:
public function updateUser(User $user) {
$store = $user->getStore();
$this->entityManager->merge($store);
$this->entityManager->persist($user);
$this->entityManager->flush();
}
You might also want to play around with Doctrine's UnitOfWork especially with getState($entity, $assumedState) to find out whether your store is still managed or not.
Let's say I've got an entity like this
class FooEntity
{
$id;
//foreign key with FooEntity itself
$parent_id;
//if no parent level =1, if have a parent without parent itself = 2 and so on...
$level;
//sorting index is relative to level
$sorting_index
}
Now I would like on delete and on edit to change level and sorting_index of this entity.
So I've decided to take advantage of Doctrine2 EntityListeners and I've done something similar to
class FooListener
{
public function preUpdate(Foo $entity, LifecycleEventArgs $args)
{
$em = $args->getEntityManager();
$this->handleEntityOrdering($entity, $em);
}
public function preRemove(Foo $entity, LifecycleEventArgs $args)
{
$level = $entity->getLevel();
$cur_sorting_index = $entity->getSortingIndex();
$em = $args->getEntityManager();
$this->handleSiblingOrdering($level, $cur_sorting_index, $em);
}
private function handleEntityOrdering($entity, $em)
{
error_log('entity to_update_category stop flag: '.$entity->getStopEventPropagationStatus());
error_log('entity splobj: '.spl_object_hash($entity));
//code to calculate new sorting_index and level for this entity (omitted)
$this->handleSiblingOrdering($old_level, $old_sorting_index, $em);
}
}
private function handleSiblingOrdering($level, $cur_sorting_index, $em)
{
$to_update_foos = //retrieve from db all siblings that needs an update
//some code to update sibling ordering (omitted)
foreach ($to_update_foos as $to_update_foo)
{
$em->persist($to_update_foo);
}
$em->flush();
}
}
The problem here is pretty clear: if I persist a Foo entity, preUpdate() (into handleSiblingOrdering function) trigger is raised and this cause an infinite loop.
My first idea was to insert a special variable inside my entity to prevent this loop: when I started a sibling update, that variable is setted and before executing the update code is checked. This works like a charm for preRemove() but not for preUpdate().
If you notice I'm logging spl_obj_hash to understand this behaviour. With a big surprise I can see that obj passed to preUpdate() after a preRemove() is the same (so setting a "status flag" is a fine) but the object passed to preUpdate() after a preUpdate() isn't the same.
So ...
First question
Someone could point me in the right direction to manage this situation?
Second question
Why doctrine needs to generate different objects if two similar events are raised?
I've founded a workaround
Best approach to this problem seem to create a custom EventSubscriber with a custom Event dispatched programmatically into controller update action.
That way I can "break" the loop and having a working code.
Just to make this answer complete I will report some snippet of code just to clarify che concept
Create custom events for your bundle
//src/path/to/your/bundle/YourBundleNameEvents.php
final class YourBundleNameEvents
{
const FOO_EVENT_UPDATE = 'bundle_name.foo.update';
}
this is a special class that will not do anything but provide some custom events for our bundle
Create a custom event for foo update
//src/path/to/your/bundle/Event/FooUpdateEvent
class FooUpdateEvent
{
//this is the class that will be dispatched so add properties useful for your own logic. In my example two properties could be $level and $sorting_index. This values are setted BEFORE dispatch the event
}
Create a custom event subscriber
//src/path/to/your/bundle/EventListener/FooSubscriber
class FooSubscriber implements EventSubscriberInterface
{
public static function getSubscribedEvents()
{
return array(YourBundleNameEvents::FooUpdate => 'handleSiblingsOrdering');
}
public function handleSiblingsOrdering(FooUpdateEvent $event)
{
//I can retrieve there, from $event, all data I setted into event itself. Now I can run all my own logic code to re-order siblings
}
}
Register your Subscriber as a service
//app/config/config.yml
services:
your_bundlename.foo_listener:
class: Your\Bundle\Name\EventListener\FooListener
tags:
- { name: kernel.event_subscriber }
Create and dispatch events into controller
//src/path/to/your/bundle/Controller/FooController
class FooController extends Controller
{
public function updateAction()
{
//some code here
$dispatcher = $this->get('event_dispatcher');
$foo_event = new FooEvent();
$foo_event->setLevel($level); //just an example
$foo_event->setOrderingIndex($ordering_index); //just an examle
$dispatcher->dispatch(YourBundleNameEvents::FooUpdate, $foo_event);
}
}
Alternative solution
Of course above solution is the best one but, if you have a property mapped into db that could be used as a flag, you could access it directly from LifecycleEventArgs of preUpdate() event by calling
$event->getNewValue('flag_name'); //$event is an object of LifecycleEventArgs type
By using that flag we could check for changes and stop the propagation
You are doing wrong approach by calling $em->flush() inside preUpdate, I even can say restricted by Doctrine action: http://doctrine-orm.readthedocs.org/en/latest/reference/events.html#reference-events-implementing-listeners
9.6.6. preUpdate
PreUpdate is the most restrictive to use event, since it is called
right before an update statement is called for an entity inside the
EntityManager#flush() method.
Changes to associations of the updated entity are never allowed in
this event, since Doctrine cannot guarantee to correctly handle
referential integrity at this point of the flush operation.
I am using Symfony 2 with Doctrine 2. I have a UserListener (symfony docs page) that listens to the PrePersist & PreRemove events for User objects. When Persisting a User, I want to create a UserInventory instance for the User. UserInventory is the owning side of the (uni-directional) association.
However with this setup, I encounter an infinite loop:
class UserListener {
/**
* Initializes UserInventory for user with initial number of nets
*/
public function prePersist(LifecycleEventArgs $args) {
$em = $args->getEntityManager();
$user = $args->getEntity();
$inventory = new UserInventory();
$inventory->setUser($user);
$inventory->setNumNets($this->initialNets);
$em->persist($inventory); // if I comment out this line, it works but the inventory is not persisted
$em->flush();
}
}
It might be that UserInventory is the owning side of the association thus, it tries to persist the user again resulting in this function called again? How can I fix this?
I want my UserInventory to own the association here because its in the "correct" bundle. I have a UserBundle but I dont think the Inventory class should be there.
UPDATE: Error/Log
You added a listener for all entites in your application. Of course, when you persist any object, e.g. UserInventory, prePersist will be called again and again.
As the symfony documentation says you can simply do a check:
if ($user instanceof User) {
$inventory = new UserInventory();
$inventory->setUser($user);
$inventory->setNumNets($this->initialNets);
$em->persist($inventory);
}
Also, I recommend to read about events in doctrine2.