symfony2 - What is the Correct LifeCycleEventArgs to use in Symfony 2.5 preUpdate Event Listener -

symfony2 - What is the Correct LifeCycleEventArgs to use in Symfony 2.5 preUpdate Event Listener -

in symfony 2.5 preupdate event listener, i'm confused whether/when pass in lifecycleeventargs or preupdateeventargs (and one).

the doctrine documentation says starting in 2.4 utilize lifecycleeventargs:

since 2.4 triggered event given lifecycle-callback. additional argument have access entitymanager , unitofwork apis within these callback methods.

but illustration straight below , subsequent examples show preupdateeventargs:

class user { public function preupdate(preupdateeventargs $event) { if ($event->haschangedfield('username')) { // when username changed. } } }

so mean lifecycleeventargs (if it's available in version) preupdateeventargs , more? both seem work (i.e. no errors).

and using new lifecycleeventargs, still necessary utilize $entity->setnewvalue('fieldname', $value)? preupdate still restrictive or can $entity->setfieldname($value)?

on doctrine 2.2, class preupdateeventargs extends lifecycleeventargs , declares entity changeset entity beingness pre-updated. yes, preupdateeventargs more, though theoretically (i.e. didn't test that!) accomplish same using em's uow:

in lifecycleeventargs, can access entity has triggered event using getentity(). same class, can access em using getentitymanager() hence: $this->getentitymanager()->getunitofwork()->getentitychangeset($this->getentity()) should give same changeset 1 provided preupdateeventargs

conclusion: preupdateeventargs facilitates job achieved using more code ;)

to dive little deeper: unitofwork::commit() triggers update calling unitofwork::executeupdates, dispatches instance of preupdateeventargs filled already-computed changeset entity, straight taken uow's changesets. (again: i'm using 2.2, might different on release.)

about $event->setnewvalue('field', 'value') vs. $entity->setfield('value'), believe need update changeset (which setnewvalue's job). calling entity's setter straight might de-synchronize entity state in db or, more probably, useless shouldn't taken consideration. except if manually phone call uow's computechangesets().

hope helps!

symfony2 doctrine2