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

Question

使用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
...

Answer 1

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

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

JPA如何处理这个问题

1. 的EntityManager(读:所述Session在Hibernate情况下)被关闭,并且脏检查机制发现挂起更改.因此,您可能已经更改了附加实体的属性,或者使用了一个附加实体的属性….persist(…).
2. 要持久化的实体使用ID生成机制.
3. 您手动调用flush方法.
4. 您触发查询并EntityManager具有挂起的更改.然后它会将这些内容刷新到数据库,以确保查询可能已经看到已更改的数据.

DataIntegrityViolationExceptions顺便说一句:最后一点有时会导致在执行查询时被抛出的奇怪效果, 并且很多人在第一时间就没有这样做.但它是在导致问题的查询执行之前刷新挂起的更改.

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

Spring Data的具体细节

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