执行findBy查询时遭遇参照完整性约束违例问题排查

• 删除顺序倒置：删除操作未遵循"先删子表、后删父表"的规则，直接先删除DeployedComponent记录，但ConnectionInfo表中仍存在指向该记录的外键数据，触发数据库参照完整性约束（SQL Error: 23503）。
• Hibernate SQL延迟执行：事务内的SQL操作被Hibernate缓存，延迟到事务提交前批量执行，导致删除ConnectionInfo的SQL晚于删除DeployedComponent的SQL执行，即使代码顺序正确也会触发约束违例。
• 关联配置缺失级联处理：ConnectionInfo与DeployedComponent的关联未配置级联删除，同时Environment的orphanRemoval仅负责移除自身关联的DeployedComponent，不会自动清理ConnectionInfo这类深层关联数据。

1. 明确删除顺序 #

在breadCrumbComponent.evaluateConditionalDependencies方法中，严格按照先清理子表、再删除父表的顺序执行：

// 先删除当前DeployedComponent关联的所有ConnectionInfo
connectionInfoRepository.deleteByDeployedComponent(deployedComponent);
// 再删除DeployedComponent记录
deployedComponentRepository.delete(deployedComponent);

2. 配置级联删除自动处理关联 #

在实体关联中添加级联删除配置，让Hibernate自动处理关联数据的清理：

• 方案一：在ConnectionInfo的@ManyToOne关联上配置级联删除

@ManyToOne(cascade = CascadeType.REMOVE)
@JoinColumn(name = "deployed_component_id")
private DeployedComponent deployedComponent;

• 方案二：在DeployedComponent的@OneToMany关联ConnectionInfo时配置级联删除

@OneToMany(mappedBy = "deployedComponent", cascade = CascadeType.REMOVE, orphanRemoval = true)
private List<ConnectionInfo> connectionInfos;

配置后，删除DeployedComponent时Hibernate会自动先删除所有关联的ConnectionInfo记录。

3. 强制SQL立即执行 #

如果因Hibernate缓存导致SQL执行顺序异常，在删除ConnectionInfo后调用flush()强制执行SQL：

connectionInfoRepository.deleteByDeployedComponent(deployedComponent);
entityManager.flush(); // 立即执行删除ConnectionInfo的SQL
deployedComponentRepository.delete(deployedComponent);

4. 校验事务与循环逻辑 #

由于updateBreadCrumbTranscation2使用Propagation.REQUIRES_NEW，每次循环调用会开启独立事务，需确保每次循环内的删除操作都在事务内完整提交，同时避免循环处理已被删除的组件。

内容的提问来源于stack exchange，提问作者Rahul Kumar