Spring Data JPA 何时在数据库上实际调用 INSERT



当您使用 JPARepository/Hibernate 保存对象时,它首先检查数据库中是否存在(使用主键),然后插入。所以我们看到 2 个日志:SELECT & INSERT。

这就是我试图通过弹簧数据做的事情:(X 和 XY 是 2 个不同的对象)

Call Save on XRepository for Object X1
Call Save on XYRepository for Object X1Y1
Call Save on XYRepository for Object X1Y2
Call Save on XYRepository for Object X1Y3
Call Save on XRepository for Object X2
Call Save on XYRepository for Object X2Y1
Call Save on XYRepository for Object X2Y2
Call Save on XYRepository for Object X2Y3

这是我在日志中的观察:

SELECT X1
INSERT X1
SELECT X1Y1
SELECT X1Y2
SELECT X1Y3
INSERT X1Y1
INSERT X1Y2
INSERT X1Y3
SELECT X2
INSERT X2
SELECT X2Y1
SELECT X2Y2
SELECT X2Y3
INSERT X2Y1
INSERT X2Y2
INSERT X2Y3

那么Spring Data什么时候真正调用插入呢?这是如何工作的?

这是我所期望的:

SELECT X1
INSERT X1
SELECT X1Y1
INSERT X1Y1
SELECT X1Y2
INSERT X1Y2
SELECT X1Y3
INSERT X1Y3
...

Spring Data JPA本身并不直接控制与数据库的交互。它所做的只是与EntityManager交互,因此实际上所有的行为效应都由JPA和底层OR映射器定义。

持久性

提供程序通常会尝试批处理数据库交互,因为这可以最大程度地减少开销,尤其是在单个会话中执行大量持久性操作时。因此,通常EntityManager只会在发生以下情况之一时将更改刷新到磁盘:

JPA 如何处理此问题

  1. EntityManager(读取:休眠情况下的Session)被关闭,脏检查机制会找到挂起的更改。因此,您可能已使用 ….persist(…) 更改了附加实体的属性或将属性添加到持久性上下文中。
  2. 要持久化的实体使用 ID 生成机制。
  3. 手动调用刷新方法。
  4. 您触发了一个查询,EntityManager具有挂起的更改。然后,它会将它们刷新到数据库,以确保查询可能已经可以看到更改的数据。

顺便说一句:最后一点有时会导致奇怪的效果 DataIntegrityViolationExceptions在查询时引发 执行,很多人一开始就没有得到。但 这是在查询执行之前刷新挂起的更改 这会导致问题。

这导致了一些重要的观察结果:

弹簧数据细节

  1. 对于非 ID 自动生成的实体,不要期望它们在关闭EntityManager之前出现在数据库中。对于 Spring 来说,这通常绑定到事务的生命周期,所以你可能需要先提交并检查更改的对象上更改的属性。
  2. 您可以查询它并检查返回的对象,而不是直接检查对象。这使用了我在上面的 4 中描述的内容。注意:不要在此方法中使用findOne(…),因为这将使用通常大量使用第一级缓存的EntityManager.find(type, id)方法(可能没有先刷新)。
  3. 作为最后的手段,您可以在JpaRepository接口上使用saveAndFlush(…),但我们强烈建议不要这样做,因为您可以有效地向客户端公开持久性层内部。首选使用自动生成的实体。

默认情况下,Hibernate在刷新期间插入保存的实体。它解释了为什么XY分批插入(在刷新期间),以及为什么saveAndFlush()立即插入它们。

但是,在插入

过程中由数据库生成的主键的实体(即生成主键并且生成策略需要实际插入才能生成键)会立即插入,因为 Hibernate 应该知道已保存实体的 ID。这就是你对X的观察.

最新更新