是否可以在postPersist中进行冲洗？ [英] Flushing in postPersist possible or not?

问题描述

我已经阅读了有关生命周期事件的文档，以及关于生命周期事件期间更改或保留新实体的一些SO问题。调用 EnitityManager :: flush（）似乎是个问题。

I have read the docs about lifecycle events, and several questions here on SO about changing or persisting new entities during lifecycle events. Calling EnitityManager::flush() seems to be a problem.

好，但是仔细查看文档，一个代码示例，其中在postPersist中更改了该字段，但是没有调用刷新。

Ok, but looking carefully at the docs, there is a code example where the field is changed in postPersist, but no flush is called.

我检查了一下，建议的更改不写入数据库。

I checked that, and the suggested change is not written to the DB. Only the object being persisted does receive the change.

<?php

/** @Entity @HasLifecycleCallbacks */
class User
{
    // ...

    /**
     * @Column(type="string", length=255)
     */
    public $value;


    /** @PostPersist */
    public function doStuffOnPostPersist()
    {
        $this->value = 'changed from postPersist callback!';
    }
}

也许应该将其添加到文档中。

Maybe one should add this to the docs. I was mislead at first.

然而，当我添加LifecyleEventArgs参数并刷新包含的EntityManager时，会将它们写入DB：

However, when adding the LifecyleEventArgs argument and flushing the contained EntityManager, they are written to DB:

/** @PostPersist */
public function doStuffOnPostPersist(LifecycleEventArgs $args)
{
    $this->value = 'changed from postPersist callback!';
    $args->getEntityManager()->flush(); // works in my tests. Is this safe to use ?

}

我不知道如何解释文档关于是否是否可以在postPersist内部调用 flush 。

I don't know how to interpret the docs about whether it is OK or not to call flush inside the postPersist.

如您所见，我正在搜索一个在插入或更新实体后对它们执行某种后处理的可靠方法。我必须使用postPersist，因为我需要自动生成的主键值。

As you can see, I am searching for a reliable way to perform some kind of postprocessing to my entities after inserting or updating them. I have to use postPersist, since I need the auto-generated primary key value.

侧面问题：如果是，则可以刷新，然后我还可以在PostUpdate中保留其他对象吗？像这样：

Side question: If yes, it is ok to flush, could I then also persist other objects in PostUpdate? Like so:

 /** @PostPersist */
public function doStuffOnPostPersist(LifecycleEventArgs $args)
{
    $this->value = 'changed from postPersist callback!';
    $obj = new OtherObject("value " . $this->value);
    $args->getEntityManager()->persist($obj);
    $args->getEntityManager()->flush(); // works in my tests. Is this safe to use ?

}

侧面问题：我尝试了最后一个变体，它似乎可以工作。但这是否有效，或者我可能会创建深度递归堆栈？根据文档，postPersist代码在刷新期间称为 ，因此，如果我在postPersist期间调用flush，则必须注意不要持久执行同一处理程序的对象，这将导致无限递归。

Side-side question: I have tried the last variant, and it seems to work. But is it efficient, or am I possibly creating deep recursion stacks? According to the docs, the postPersist code is called during flush, so if I call flush during postPersist, I have to be careful not to persist an object that executes the same handler, which would lead to infinite recursion. Is this correct?

推荐答案

我检查了一下，建议的更改未写入数据库。

I checked that, and the suggested change is not written to the DB. Only the object being persisted does receive the change.

也许应该将其添加到文档中。起初我是误导。

Maybe one should add this to the docs. I was mislead at first.

文档中的代码不会尝试将对值属性
的修改保留在数据库中，这就是为什么没有调用 flush（）。只是显示一个示例，该值也可能未映射到类 User 的数据库属性。

The code in the docs doesn't try to persist this modification of the value property in database that's why no flush() is called. It's just show an example and this value could also be an unmapped to the database property of class User.

我不知道如何解释文档是否可以在postPersist内部调用flush。

I don't know how to interpret the docs about whether it is OK or not to call flush inside the postPersist.

可以调用在PostPersist生命周期回调中 flush（）来更改实体的映射属性
。在PostPersist回调中，您的实体已插入数据库中。通过更改属性
的值并调用 flush（），您的实体将被标记为要更新，因此PostPersist事件将不会分派

It is ok to call flush() on a PostPersist lifecycle callback in order to change a mapped property of your entity. In your PostPersist callback your entity has already been inserted in your database. By changing the property value and calling flush() your entity will be flag as to be updated, so the PostPersist event won't be dispatched again (instead Pre/PostUpdate events will be dispatched).

另一个问题：如果是的话，可以刷新，然后我还可以持久化其他对象吗？ PostUpdate？

Side question: If yes, it is ok to flush, could I then also persist other objects in PostUpdate?

将另一个实体类的新对象持久保存在PostPersist事件回调中也是可以的，
也是可以的，但是如果尝试在此PostPersist回调中保留相同（用户）类的对象，您将可以轻松地理解
的无限递归。

It is also ok to persist an new object of another entity class in a PostPersist event callback with no problem, but if you try to persist an object of the same (User) class in this PostPersist callback you will have an infinite recursion, as you can easily understand.

侧面问题：我尝试了最后一个变体，它似乎起作用。但这是有效的，还是我可能会创建深度递归堆栈？

Side-side question: I have tried the last variant, and it seems to work. But is it efficient, or am I possibly creating deep recursion stacks?

正如我在此代码之前所解释的那样，不会创建太深的递归堆栈或无限如果没有持久化回调所属的同一类（用户）的对象，则循环。 flush（）将被精确调用两次。尽管在还要处理关联时事情可能会变得更加复杂，但在您的示例中就没有这种问题。

As I have explained before this code doesn't create too deep recursion stacks or infinite loops if not persisting objects of the same class (User) in which the callback belongs. The flush() will be called exactly two times. Although things could get more complicated when having also to deal with associations, in your example there is not such problem.

这篇关于是否可以在postPersist中进行冲洗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！