gpt4 book ai didi

java - 不同用例的不同 CascadeType 值

转载 作者:太空宇宙 更新时间:2023-11-04 11:16:47 24 4
gpt4 key购买 nike

对于 JPA,我在实体类中定义 Cascade Type 和 orphanRemoval 设置等内容时遇到问题。对我来说,在实体上定义 Cascade Type 和 orphanRemoval 是有限制的,因为它假设您始终希望这些设置在所有场景中都相同。

但是,我可以想到很多情况,应用程序有时可能需要 orphanRemoval,有时则不需要给定实体的 orphanRemoval。同样,应用程序有时可能需要一种级联类型,而有时则需要同一实体的不同级联类型。

我希望实体管理器允许您在进行合并、持久化等操作时指示级联类型(或 orphanRemoval)应该是什么,但我认为 api 不支持这一点。

是否可以针对不同场景使用不同的级联类型或orphanRemoval值?

我发现了这个问题JPA programmaticaly define cascading options它提出了类似的问题,答案似乎是不可能的,至少对于级联类型是不可能的。我开始认为我不应该对我的任何关系使用级联类型/orphanRemoval,这意味着在我确实希望保存/更新子级的情况下,我将不得不手动执行此操作。

最佳答案

To me, defining Cascade Type and orphanRemoval on the Entity is limiting as it assumes you always want these settings to be the same in all scenarios.

我发现这个假设是合理的,因为实体中的级联设置直接与底层数据库中相应外键 (FK) 约束的引用完整性 (RI) 操作相关。如果我们希望这些规则在“数据库”级别(对应于 Hibernate 中的“实体”级别)自动执行,那么数据库通常期望遵循一个规则,例如,

ALTER TABLE Sales.TempSalesReason     
ADD CONSTRAINT FK_TempSales_SalesReason FOREIGN KEY (TempID)
REFERENCES Sales.SalesReason (SalesReasonID)
ON DELETE CASCADE
ON UPDATE CASCADE
;

如果我们希望在不同的情况下应用不同的 RI 规则,则由我们的应用程序代码通过对子表执行自己的 UPDATE 或 DELETE 操作,或者通过阻止初始数据库操作来强制执行这些规则,否则会触发 FK 约束中的 RI 规则(如果有)。

关于java - 不同用例的不同 CascadeType 值,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45384597/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com