java - OneToMany 上 CascadeType (DETACH/REMOVE/REFRESH) 的实际用法？

Question

我真的很难找到在 OneToMany 关系中 CascadeType.DETACH、CascadeType.MERGE、CascadeType.REFRESH 的真实世界用法。

举个例子:

User hasMany UserAccess 

每次用户登录网站时，都会创建一个包含他的 IP 地址和日期时间的 UserAccess 对象。

1. 上面的 03 CascadeTypes 如何影响现实世界程序中的这种关联？我几乎可以看到 CascadeType.PERSIST(用于级联持久化)和 CascadeType.REMOVE(如果用户被删除则删除 child )的用法。毫无疑问，OrphanRemoval 在这种情况下也是可笑的。

2. 如果我的例子不够完整，谁能就这个主题制定一个现实世界的例子？

谢谢!

Answer 1

我很难思考您的示例，因为分离和合并往往适用于将在您的影响范围之外访问的实体。出于这个原因，我将坚持使用一些无聊的示例，例如文档集合。

在进入示例之前有两点:

首先，理解 Hibernate 级联的一个有用的经验法则是这样想:“如果我将操作 X 从 A 级联到 B，那么当我在 A 上调用操作 X 时，Hibernate 将自动在所有的相关的 B。(孤儿删除是一个异常(exception))”

其次，考虑到这一点，除了孤儿移除之外，所有级联的优势只是为您省去了遍历子对象和调用子对象操作的麻烦。你自己做和让 Hibernate 做之间没有功能上的区别。

现在，举个例子:

假设您的应用程序跟踪一个 DocumentCollection 对象，该对象具有许多 Document 对象，而 Document 对象又具有许多 Paragraph 对象。您希望此应用程序由其他团队构建的桌面界面使用。您的团队拥有后端，另一个团队拥有前端，但不是 Web 应用程序，所有这些都发生在同一进程中。

为简单起见，该接口(interface)将获取一个 DocumentCollection 批发，因此您的公共(public) API 将只是:

public DocumentCollection fetchCollection(String collectionName);
public void updateCollection(DocumentCollection collection);

现在，因为您不知道界面团队在获取您的 DocumentCollection 之后将如何处理它，那么您最不想做的就是将一个实时的、持久的实体传回给他们，事务管理本身就可以太可怕了。要解决此问题，您需要在发送之前分离任何内容。

现在通常你不需要分离任何东西，因为无论如何你都会在返回对象之前关闭你的 session ，所以让事情变得更复杂。让我们假设您的用户正在与一些多页表单小部件进行交互，并且您希望在小部件的持续时间内保持 session 打开(这是每次对话的 session ，但老实说，如果您考虑这个示例太久，它会变得人为但这是我能想到的最好的事情)。

所有这些确实证明了为什么您首先要分离某些东西，我怀疑这比您想象的更能成为您问题的核心。因此，鉴于这种人为设计的场景，您的选择是:

1. 对 DocumentCollection 调用 detach，遍历每个 Document 并对其调用 detach，然后遍历每个 Paragraph 并对其调用 detach。
2. 对 DocumentCollection->Document 和 Document->Paragraph 关系进行级联分离，然后只对 DocumentCollection 调用分离，让 Hibernate 为您进行迭代。

当然，一旦用户完成修改文档并将其传回以保存它，那么您将不得不对所有内容调用合并，因此级联合并将非常有用。

为了刷新，让我们看一个不同的例子(这个例子可能更做作，因为我自己没有做过)。假设您决定信任您的界面团队并且您不想分离对象。这允许您跳过分离和合并的调用。现在，假设用户点击了某种“恢复到上次保存”按钮。您决定通过“刷新”DocumentCollection 和下面的所有内容来实现它。在这里，级联会非常有用，因为它会为您节省大量迭代。