删除元素时使用 JoinTable 和 OrderColumn 的 Hibernate 单向 OneToMany 映射中的约束冲突

Question

从如上所述映射的列表中删除元素时遇到问题。这是映射：

@实体 @表（名称=“富”） 类Foo { 私人列表酒吧； @OneToMany @OrderColumn( 名称 = "order_index" ) @JoinTable(name = "foo_bar_map", joinColumns = @JoinColumn(name = "foo_id"), inverseJoinColumns = @JoinColumn(name = "bar_id")) @Fetch(FetchMode.SUBSELECT) 公共列表 getBars() { 返回栏； } }

插入 Bar 实例并保存 Foo 工作正常，但是当我从列表中删除一个元素并再次保存时，违反了映射表中 bar_id 的唯一约束。以下 SQL 语句由 hibernate 发出，它们看起来很奇怪：

日志：执行：从 foo_bar_map 中删除，其中 foo_id=$1 和 order_index=$2 详细信息：参数：$1 = '4'，$2 = '6' 日志：执行 S_5：更新 foo_bar_map 设置 bar_id=$1 其中 foo_id=$2 和 order_index=$3 详细信息：参数：$1 = '88'，$2 = '4'，$3 = '0' 错误：重复键值违反唯一约束“foo_bar_map_bar_id_key”

鉴于 Hibernate 生成的语句（列表中有五个项目，我删除第一个项目，Hibernate 删除带有 LAST 索引的映射行并尝试更新其余的，从第一个）。

上面的映射有什么问题？

Answer 1

通常当通过连接表连接时，关系是多对多而不是单对多。试试这个

@ManyToMany
@OrderColumn( name = "order_index" )
@JoinTable( name = "foo_bar_map", joinColumns = @JoinColumn( name = "foo_id" ), inverseJoinColumns =  @JoinColumn( name = "bar_id" ) )
@Fetch( FetchMode.SUBSELECT )
public List getBars() {
    return bars;
}

Answer 2

我猜你需要的是正确的逆映射。
http://docs.jboss.org/hibernate/core/3.3/reference/en/html/tutorial.html#tutorial-associations-bidirectional

Answer 3

您的映射完全有效，并且可以与 EclipseLink 作为 JPA 2.0 实现一起使用（当然没有 Fetch 注释），但在 Hibernate 中确实失败了。

这是带有 Hibernate 的 DDL：

create table foo_bar_map (foo_id bigint not null, bar_id bigint not null, order_index integer not null, primary key (foo_id, order_index), unique (bar_id))
alter table foo_bar_map add constraint FK14F1CB7FA042E82 foreign key (bar_id) references Bar4022509
alter table foo_bar_map add constraint FK14F1CB7B6DBCCDC foreign key (foo_id) references Foo4022509

假设Foo#1 拥有一个包含Bar#1、Bar#2、Bar#3 的列表，连接表包含：

foo_id | bar_id | order_index
     1 |      1 |           1
     1 |      2 |           2
     1 |      3 |           3

当删除时，比如说列表中的第一项，Hibernate 首先delete 连接表中的最后一行（WTF？）：

foo_id | bar_id | order_index
     1 |      1 |           1
     1 |      2 |           2

然后尝试update 连接表中的bar_id 列而不是order_index（WTF！？）以反映列表中项目的“新”顺序。首先（示意图）：

foo_id | bar_id | order_index
     1 |      2 |           1
     1 |      2 |           2

下一步将导致：

foo_id | bar_id | order_index
     1 |      2 |           1
     1 |      3 |           2

显然，由于bar_id 上的unique 约束，这种方法听起来不正确并且不起作用。更一般地说，为什么 Hibernate 会搞乱bar_id 而不是更新order_index 列？

我认为这是一个 Hibernate 错误（报告为 HHH-5694，现在请参阅 HHH-1268）。

Answer 4

不，我不认为这是一个休眠错误，如果您进行搜索，您会看到 Pascal Thivent 引用的这个休眠错误是自 2006 年以来已知的一个错误，并且从未得到解决。

为什么？

因为我认为问题只是在表上的约束而不是在休眠中。

我不明白为什么 bar_id 有唯一约束

使用订单索引意味着您的集合是一个列表（而不是一个集合！）。 List 是一个集合，您可以在其中为您添加的元素指定索引（它对应于 OrderColumn）。
List 和 Set 之间的区别在于您可以两次（或更多）相同的数据，但相同的数据将位于不同的索引处。 然后你可以有相同的 bar_id 不同的索引，你不必在 bar_id 上指定唯一的约束。 并且主键不能是 (foo_id, order_index) 导致模式 List 在不同的索引处授权相同的数据。 也许你的 PK 应该是 (foo_id, bar_id, order_index) ？

我认为问题出在这种方式:)