双向OneToMany与ManyToOne关联保存时触发‘scale_id列不允许为NULL’异常排查

这个问题的核心是双向关联关系没有被正确维护，咱们一步步拆解：

问题根源 #

你在代码里只把SubScale对象加到了Scale的subScales集合中，但没有给这些SubScale对象设置对应的scale属性。虽然你在Scale的@OneToMany注解里配置了cascade = CascadeType.ALL，会让JPA级联保存关联的SubScale，但数据库中sub_scale表的scale_id字段是带非空约束的——而这些新添加的SubScale的scale属性为null，对应到数据库就是scale_id为null，自然触发了约束异常。

要记住：JPA的双向关联需要同时维护两边的关系。@ManyToOne的一方是关系的「拥有方」（因为外键在它对应的表中），必须保证这个拥有方的关联字段不为空；而@OneToMany的mappedBy属性只是声明这是反向关联，不会自动同步拥有方的字段值。

修复方案 #

1. 给Scale实体添加维护关联的辅助方法 #

在Scale类里新增一个方法，把关联维护的逻辑封装在实体内部，避免业务代码出错：

public void addSubScale(SubScale subScale) {
    this.subScales.add(subScale);
    subScale.setScale(this); // 关键：给SubScale设置对应的Scale实例
}

2. 修改accumulateScale方法中的关联更新逻辑 #

把原来直接用addAll的代码替换成调用上面的辅助方法，同时修正移除逻辑的判断条件：

if (request.isSubScaleSelected() && !request.getSubScales().isEmpty()) {
    // 处理需要新增的SubScale：逐个调用addSubScale维护双向关联
    Sets.difference(request.getSubScales(), scale.getSubScales())
        .forEach(scale::addSubScale);
    
    // 处理需要移除的SubScale：移除不在请求列表中的元素
    scale.getSubScales().removeIf(subScale -> !request.getSubScales().contains(subScale));
}

这里要注意，你原来的removeIf逻辑写反了，改成判断元素是否不在请求集合里，才能正确同步最新的关联数据。

额外优化建议 #

可以再给Scale添加一个移除关联的辅助方法，保证移除时也能同步清理双向关系：

public void removeSubScale(SubScale subScale) {
    this.subScales.remove(subScale);
    subScale.setScale(null);
}

这样在后续处理移除操作时，能避免出现脏数据或关联残留的问题。

内容的提问来源于stack exchange，提问作者Vardan Momjyan