Symfony preUpdate vs prePersist [英] Symfony preUpdate vs prePersist

问题描述

我是Symfony2的新手，我想知道prePersist和preUpdate事件有什么区别。在我坚持记录之前，看起来prePersist是被解雇，但是什么时候预先启动？

解决方案

是Symfony的一部分。它们是Doctrine2的一部分。一个实体首先被持久化，触发 prePersist 。持久化对象意味着它由Doctrine entityManager管理，即使在直到刷新之前，它并没有真正被插入到数据库中。

preUpdate 是现有对象即将更新的相应事件。因为现在的对象在被查询的时候已经被entityManager管理了，所以没有等同的持久化事件。当现有对象被更改时，它基本上触发，并且已经调用了flush。

换句话说，如果你没有不要更改对象中的任何内容，PreUpdate将不会运行！

正如上所述，您可以将这些事情看作插入前和

还有两种形式：生命周期回调，可以直接注释到实体中并添加为方法在它的内部，但只能访问实体属性。这些可以很好地适用于简单的操作，如时间戳，符合特定标准的字符串或生成派生属性。

还有真实的事件侦听器必须向entityManager注册，并且可以访问具有在数据库触发器中期望的数据之前/之后的类型的事件数据。

请注意，在 Doctrine版本2.4他们添加了事件数据即使是生命周期回调，现在它使您以前需要使用事件侦听器的同样的事情变得更加简单和容易。 p>

I am new to Symfony2 and I would like to know what is the difference in prePersist and preUpdate events. It looks like prePersist is 'fired' before I 'persist' a record, but when does preUpdate fire?

解决方案

Neither of these is part of Symfony specifically. They are part of Doctrine2. The prePersist fires at the point that an entity is first persisted. Persisting an object means that it is managed by the Doctrine entityManager, even though it does not actually get inserted into the database until a flush.

preUpdate is the corresponding event on an existing object that is about to be updated. Because an existing object is already managed by the entityManager at the point that it was queried, there is no equivalent persist event. It basically fires when an existing object has been changed, and a flush has been called.

In other words, if you didn't change anything in the object, PreUpdate will not run!

With that said, you can think of these as happening "just before insert" and "just before update".

There are also 2 forms of these: lifecycle callbacks, which can be annotated directly into the entity and added as methods inside of it, but only have access to the entity attributes. These can be good for simple manipulations like timestamping, conforming strings to a particular standard, or generating derived attributes.

There are also true event listeners which have to be registered with the entityManager, and have access to event data that has the type of before/after data you'd expect in a database trigger.

Note that in Doctrine version 2.4 they added event Data even for Lifecycle callbacks, which now makes it far simpler and easier to do the same sorts of things you previously needed to use event listeners for.

这篇关于Symfony preUpdate vs prePersist的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！