Wie überprüft man, ob Entität in Doctrine 2 geändert wurde?

Question

Ich muss überprüfen, ob sich eine persistente Entität geändert hat und in der Datenbank aktualisiert werden muss. Was ich gemacht (und funktionierte nicht) war die folgende:

$product = $entityManager->getRepository('Product')->find(3); 
$product->setName('A different name'); 

var_export($entityManager->getUnitOfWork()->isScheduledForUpdate($product)); 

Dieser Code druckt immer false, versuchte ich auch, bevor überprüfen die Arbeitseinheit zu spülen, aber hat nicht funktioniert.

hat jemand einen Vorschlag?

Answer 1

Das erste, was ich überprüfen würde, dass Ihre setName Funktion tatsächlich etwas tut ($ this-> name = $ name ...) Wenn es bereits funktioniert, dann könnten Sie einen Ereignis-Listener auf Ihre Dienste definieren .yml, die ausgelöst wird, wenn Sie den Flush aufrufen.

entity.listener: 
    class: YourName\YourBundle\EventListener\EntityListener 
    calls: 
    - [setContainer, ["@service_container"]] 
    tags: 
    - { name: doctrine.event_listener, event: onFlush } 

Dann definieren Sie die EntityListener

namespace YourName\YourBundle\EventListener; 

use Doctrine\ORM\Event; 
use Symfony\Component\DependencyInjection\ContainerAware; 

class EntityListener extends ContainerAware 
{ 

    /** 
    * Gets all the entities to flush 
    * 
    * @param Event\OnFlushEventArgs $eventArgs Event args 
    */ 
    public function onFlush(Event\OnFlushEventArgs $eventArgs) 
    { 
     $em = $eventArgs->getEntityManager(); 
     $uow = $em->getUnitOfWork(); 

     //Insertions 
     foreach ($uow->getScheduledEntityInsertions() as $entity) { 
      # your code here for the inserted entities 
     } 

     //Updates 
     foreach ($uow->getScheduledEntityUpdates() as $entity) { 
      # your code here for the updated entities 
     } 

     //Deletions 
     foreach ($uow->getScheduledEntityDeletions() as $entity) { 
      # your code here for the deleted entities 
     } 
    } 
} 

Wenn Sie wissen müssen, welche Elemente geändert werden, sondern etwas mit ihnen nach haben sie in der Datenbank gespeichert sind, nur speichern die Entitäten, die in einem privaten Array geändert wurden, und dann ein onFlush-Ereignis definieren, das die Entitäten aus dem Array abruft.

BTW, diese Art von Ereignissen auslösen Sie die @ORM \ HasLifecycleCallbacks auf die Entität hinzufügen müssen.

Answer 2

Sie können sich auch an der PreUpdate Veranstaltung suchen möchten, wenn Sie den Zugriff auf Unternehmens Felder mit ihren alten und neuen Werte müssen.

Ein bisschen Beispiel überwiegend aus dem darin enthaltenen Link genommen:

<?php 
class NeverAliceOnlyBobListener 
{ 
    public function preUpdate(PreUpdateEventArgs $eventArgs) 
    { 
     if ($eventArgs->getEntity() instanceof User) { 
      if ($eventArgs->hasChangedField('name') && $eventArgs->getNewValue('name') == 'Alice') { 
       $oldValue = $eventArgs->getOldValue('name'); 
       $eventArgs->setNewValue('name', 'Bob'); 
      } 
     } 
    } 
} 

Answer 3

ich nicht/brauchte Zuhörer für meinen Fall zu schaffen, so landete ich mit

$product->setName('A different name'); 
$uow = $entityManager->getUnitOfWork(); 
$uow->computeChangeSets(); 
if ($uow->isEntityScheduled($product)) { 
    // My entity has changed 
} 

Answer 4

Doctrine2 Docs. 17. Change Tracking Policies

up

wenn Sie dritte Form, wie ich tun, können Sie testen, ob Ihr Unternehmen geändert tut (17.3 benachrichtigen.):

Wenn nichts geändert wird es leer Array zurück.

Answer 5

Das Problem ist ziemlich alt, aber es kann immer noch einige Gruppe von Menschen, die dieses Problem aus einer anderen Sicht konfrontiert sein könnten. Die UnitOfWork funktioniert gut, aber es gibt nur das Array der Änderungen zurück. Es kann ein Schmerz im Hintern sein, wenn jemand nicht wirklich weiß, welche Felder sich geändert haben könnten und nur die ganze Entität als ein Objekt zum Vergleichen $oldEntity und $newEntity erhalten möchte. Auch wenn der Name der Veranstaltung Preupdate ist, wenn jemand versuchen, die Daten aus der Datenbank zu holen, wie folgt:

$er->find($id); 

der zurück Unternehmen alle Änderungen enthalten. Die Abhilfe ist ziemlich einfach, aber es hat einige Haken:

public function preUpdate(Entity $entity, PreUpdateEventArgs $args) 
{ 
    $entity = clone $entity; //as Doctrine under the hood 
          //uses reference to manage entities you might want 
          //to work on the entity copy. Otherwise,   
          //the below refresh($entity) will affect both 
          //old and new entity. 
    $em = $args->getEntityManager(); 
    $currentEntity = $em->getRepository('AppBundle:Entity')->find($entity->getId()); 
    $em->refresh($currentEntity); 

} 

Für diejenigen, die ein anderes Ereignis verwenden, wie Vorspülen, ich habe es schnell überprüft und die Abhilfe gut funktionierte nicht, weil wahrscheinlich die refresh() Methode verwirft Jede Flush-Änderung, also was getan werden muss, ist, den Flush erneut im Listener aufzurufen und einen statischen $alreadyFlushed-Toggle zu erzeugen, um eine zirkuläre Referenz zu vermeiden.

Answer 6

Ich bin neugierig auf Doctrine und alle, die postFlush dokumentieren, denn in einigen Fällen haben Sie eine laufende Transaktion. Ich möchte darauf hinweisen, dass es auch postTransactionCommit gibt, was je nachdem, was Sie im postFlush-Ereignis erreichen möchten, sicherer sein könnte.

Answer 7

Basierend auf meinen Bedürfnissen, Antworten hier und the docs, kam ich mit der folgenden Lösung für einen modifiedAt Zeitstempel in einer Entität.

/** 
* @Doctrine\ORM\Mapping\PreUpdate() 
* 
* @param \Doctrine\ORM\Event\PreUpdateEventArgs $args 
* @return $this 
*/ 
public function preUpdateModifiedAt(\Doctrine\ORM\Event\PreUpdateEventArgs $args) 
{ 
    $this->setModifiedAt(new \DateTime('now')); 

    return $this; 
} 

Dies basiert auf what the docs say diesen Event zu den anderen verfügbaren Gegensatz wie PostPersist und PreFlush:

Preupdate die restriktivsten ist Ereignis zu bedienen, es da Recht genannt wird bevor eine update-Anweisung für eine Entität innerhalb der EntityManager # flush() -Methode aufgerufen wird. Beachten Sie, dass dieses Ereignis nicht ausgelöst wird, wenn das berechnete Änderungsset leer ist.

Mit PreUpdate als Gegensatz zu den anderen können Sie verlassen alle Berechnungen und rechenintensiven Funktionen für den Prozess bereits durch Lehre definiert. Das manuelle Auslösen der Berechnung von Changesets, wie zum Beispiel in theseanswers oben, sind Server-CPU-intensiv. Das onFlush-Ereignis, wie es in the accepted answer verwendet wird, ist eine Option (in der dargestellten Weise), aber nicht, wenn Sie sich auf eine Änderung der Entität verlassen, wie Sie es mit der obigen Funktion tun können (preUpdateModifiedAt(PreUpdateEventArgs $args)).