2020-05-12更新:因为我们的业务并不允许使用jpa的级联操作以及mysql的外键,所以只是学习了这篇文章但是并没有试过其中的代码。今天想起来把代码测试了一遍,并修正了文中的一些说法。
这是我看过的解释的最清楚的一篇文章。本来只想放个链接,但是怕链接原文被删了,所以把原文也复制过来并重新排版。感谢作者。
原文链接:http://westerly-lzh.github.io/cn/2014/12/JPA-CascadeType-Explaining/
1. 背景
网上关于JPA的CascadeType讲解很多,但几乎都说的很模糊。本文试图使用一个具体的例子来说明CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH, CascadeType.REMOVE, CascadeType.ALL 具体区别。
我们使用一个订单和订单项的例子。该例子在网络上那些介绍JPA CascadeType用法的文章中广为流传。
2. 使用的代码
/**
* 订单
*/
@Entity
@Table(name="t_order")
public class Order {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
@Column
private String name;
@OneToMany(mappedBy="order",targetEntity=Item.class,fetch=FetchType.LAZY)
private List<Item> items;
}
/**
*订单物品
*/
@Entity
@Table(name="t_item")
public class Item {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Integer id;
@Column
private String name;
@ManyToOne(fetch=FetchType.LAZY,targetEntity=Order.class)
@JoinColumn(name="order_id")
private Order order;
}
/** Order Repository */
public interface OrderRepository extends JpaRepository<Order, Integer>,
JpaSpecificationExecutor<Order> {
}
/** Item Repository */
public interface ItemRepository extends JpaRepository<Item, Integer>,
JpaSpecificationExecutor<Item> {
}
通过jpa自动建表,这时候item表中有一个字段order_id,是order表的id,这是一个外键约束,记住这一点,很重要。
3. 新增(保存)数据(CascadeType.PERSIST)
客户每次下完订单后,需要保存Order,但是订单里含有Item,因此,在保存Order时候,Order相关联的Item也需要保存。采用上面的模型,使用如下的测试代码:
@Test
public void addTest(){
Order order = new Order();
order.setName("order1");
Item item1 = new Item();
item1.setName("item1_order1");
item1.setOrder(order);
Item item2 = new Item();
item2.setName("item2_order1");
item2.setOrder(order);
List<Item> items = new ArrayList<Item>();
items.add(item1);
items.add(item2);
order.setItems(items);
//代码段1
orderRepository.save(order);
Assert.assertEquals(1,orderRepository.count());
Assert.assertEquals(2,itemRepository.count());
//代码段2
itemRepository.save(items);
Assert.assertEquals(1,orderRepository.count());
Assert.assertEquals(2,itemRepository.count());
}
3.1 在该场景中,我们分别测试了如下情况:
CascadeType的用法 | 代码段1结果 | 代码段2结果 |
---|---|---|
不使用CascadeType | order可以保存到数据库,item不能 | 报错,因为外键使用的order_id不存在 |
单独在Order类的items属性上加入CascadeType.PERSIST | order和items都可以保存到数据库 | 报错,同上 |
单独在Item类的order属性上加入CascadeType.PERSIST | order可以保存到数据库,item不能 | order和items都可以保存到数据库 |
在Order和Item类中都使用CascadeType.PERSIST | order和items都可以保存到数据库 | order和items都可以保存到数据库 |
3.5 结论
在某个类的某个级联属性上使用CascadeType.PERSIST
,对该类进行保存操作时,可以级连保存该类中此属性所对应的对象;而对该类的属性对应的对象进行保存操作时,却不能保存该类;存在外键的一方时,因为外键的约束并不能单独保存。
如果在该类和该类的属性所对应的类别中同时使用CascadeType.PERSIST
,无论是从该类出发进行保存操作,还是从该类的属性对应的对象出发进行保存操作,都可以保存二者。
4. 删除数据(CascadeType.REMOVE)
现在有这样的场景,客户需要删除一个订单,那么订单中的订单项也需要一并删除,为了可以实现级连删除的效果,我们使用以下测试代码:
@Test
public void testDelete(){
//代码段3
orderRepository.delete(order);
Assert.assertEquals(0, orderRepository.count());
Assert.assertEquals(0, orderRepository.count());
//代码段4
itemRepository.delete(items);
Assert.assertEquals(0, orderRepository.count());
Assert.assertEquals(0, itemRepository.count());
}
4.1 在该场景中,我们分别测试如下情况:
CascadeType的用法 | 代码段3结果 | 代码段4结果 |
---|---|---|
不使用CascadeType | 报错,被item的order_id外键约束 | 删除item,不能删除order |
在Order类的items属性上使用CascadeType.REMOVE | 级连删除order中items的Item对象;在删除过程中,会先删除items,然后再删除order | 可以删除item,不能删除order |
在Item类的order属性上使用CascadeType.REMOVE | 报错,被item的order_id外键约束 | 可以删除items及其级联的order对象,其过程是先更新items中引用的order的外键,设置items对order的引用为空值;如果只删除一个item,order仍有级联的item没有删除,此时并不是删除某一个item,而是都不能删除,报错,外键约束 |
在Order和Item中都使用CascadeType.REMOVE | order和items都被删除 | order和items都被删除;如果只删除部分item,order仍有级联的item未被删除,报错同上 |
4.2 结论
在一般的业务场景中,需求基本是在删除order时同时级连删除items,但反过来,在删除items的时候同时也要求删除order却不是很适合;即使删除了所有和order相关的items,可能也需要保持住那个没有items的order。
这里的建议是,最好不要在Item类使用CascadeType.REMOVE,一是不符合业务场景要求,二是外键约束报错的概率99.9999999999...%
。
5. 更新数据(CascadeType.MERGE)
在业务上,经常会有这样一种类似的需要:查找到了一个业务实体后,要更新该实体,同时也需要更新该实体所关联的其他业务实体。在我们的例子中就是,同时需要更新Order和其所关联的Item。我们使用如下测试代码:
@Test
public void testUpdate(){
order.setName("order1_updated");
items.get(0).setName("item1_order1_updated");
items.get(1).setName("item2_order1_updated");
//代码段5
orderRepository.save(order);
Assert.assertEquals(1, orderRepository.count(new Specification<Order>(){
public Predicate toPredicate(Root<Order> root, CriteriaQuery<?> cq, CriteriaBuilder cb) {
return cb.equal(root.get("name").as(String.class), "order1_updated");
}
}));
Assert.assertEquals(1, itemRepository.count(new Specification<Item>() {
public Predicate toPredicate(Root<Item> root,CriteriaQuery<?> cq, CriteriaBuilder cb) {
return cb.equal(root.get("name").as(String.class), "item1_order1_updated");
}
}));
//代码段6
itemRepository.save(items);
Assert.assertEquals(1, itemRepository.count(new Specification<Item>() {
public Predicate toPredicate(Root<Item> root,CriteriaQuery<?> cq, CriteriaBuilder cb) {
return cb.equal(root.get("name").as(String.class), "item1_order1_updated");
}
}));
Assert.assertEquals(1, orderRepository.count(new Specification<Order>(){
public Predicate toPredicate(Root<Order> root, CriteriaQuery<?> cq, CriteriaBuilder cb) {
return cb.equal(root.get("name").as(String.class), "order1_updated");
}
}));
}
在该场景中,我们分别测试如下情况:
CascadeType的用法 | 代码段5结果 | 代码段6结果 |
---|---|---|
不CascadeType.MERGE | 更新Order成功,不会级连更新items | 更新items成功,不会级联更新items所关联的order对象 |
单独在Order的items属性上使用CascadeType.MERGE | 更新order成功,并且级连更新items | 更新items成功,不会级联更新order |
单独在Item的属性order上使用CascadeType.MERGE | 更新order成功,不会级联更新items | 更新items成功,可以级连更新其关联的order对象 |
在Order和Item中都使用CascadeType.MERGE | 更新order成功,并且级连更新items | 更新items成功,可以级连更新其关联的order对象 |
5.2 结论
通过使用CascadeType.MERGE,可以说是最容易理解的,理解了上面的PERSIST和REMOVE,MERGE就没有问题。
6. 刷新数据(CascadeType.REFRESH)
这里刷新数据,是对应在这样的业务场景下:对于业务系统,一般会存在多个用户,如果用户A取得了order和其对应的items,并且对order和items进行了修改,同时用户B也做了如此操作,但是用户B先保存了,然后用户A保存时,需要先刷新order关联的items,然后再把用户A的变更更新到数据库。这中场景就对应了CascadeType.REFRESH的需求。