重新连接实体树后的Eclipse Link奇怪行为 [英] Eclipse Link strange behavior after re attaching entity tree

查看:85
本文介绍了重新连接实体树后的Eclipse Link奇怪行为的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个标准的JEE7应用程序,使用Eclipse Link作为JPA引擎,并且实体树将所有在其OneToMany关系中以CascadeType.ALL注释的实体.所有实体都具有数据库序列中的@GeneratedValue id.

I have a standard JEE7 application using Eclipse Link as JPA engine and an Entity tree will all entities annotated with CascadeType.ALL in their OneToMany relationships. All Entities have @GeneratedValue ids from database sequences.

在事务处理期间,我已获取实体树的托管实例,然后分离根,然后将树的所有@Id字段和@Version字段设置为null并合并根实体.

During a transaction I have fetched a managed instance of an Entity tree, then I detach the root then set null to all @Id fields and @Version fields of the tree and merge the root Entity.

我希望树中除两个之外的所有托管实体都具有新的ID.问题是2个不同类型的实体在其id字段中保留null,并且在提交时出现以下异常:

As I expect all managed Entities in the tree, except from two, have new Ids. The problem is that 2 entities of different type retain the null in their id fields and when committing I'm getting the following Exception:

org.eclipse.persistence.exceptions.ValidationException
Exception Description: Null or zero primary key encountered in unit of work clone [EntityA [id=null, businessId=17EN000000000083]], primary key [null]

我尝试了对equals和hashCode方法的几次更改,主要是在EntityA中避免两个实体相等(如果两个实体的id均为null的话),但是什么也没有发生.该行为不是确定性的,在调试过程中有时会生成id,但通常为null.

I tried several changes in equals and hashCode methods in that EntityA mainly to avoid regarding two entities equals if their ids are null in both of them, but nothing happened. The behavior is not deterministic, during debugging sometimes the id was generated but usually is null.

任何人都可以给这个问题一个提示.

Could anyone give a hint for the problem.

-编辑

当我们在问题关系中使用FetchType.EAGER而不是FetchType.LAZY时,merge会按预期创建ID.谁能解释为什么会这样?

When we used FetchType.EAGER instead of FetchType.LAZY in problematic relationship, the merge created the ids as expected. Could anyone explain why this happens?

推荐答案

除非您要序列化实体,否则它并不是真正分离的. EclipseLink具有允许在上下文仍然可用的情况下获取懒惰关系的功能,这在很大程度上意味着直到EntityManagerFactory关闭或实体被序列化为止.因此,如果您分离"您的实体并遍历一个懒散的,未提取的关系,则将从执行初始读取的EntityManager中读取引用的实体并进行管理.

Unless you are serializing your entity, it is not really detached. EclipseLink has functionality that allows fetching lazy relationships as long as the context is still available, which pretty much means until the EntityManagerFactory is closed or the entity is serialized. So if you 'detach' your entity and traverse a lazy, unfetched relationship, the referenced entities will be read in from the EntityManager that performed the initial read, and be managed.

尽管如此,由于跟踪变更和其他工件已融入到您的实体中,因此,如果您希望使用新的标识来保留数据,则最好复制您的实体.

Regardless of that, since change tracking an other artifacts get woven into your entities, you are better off copying your entity if you wish to persist the data with a new identity.

这篇关于重新连接实体树后的Eclipse Link奇怪行为的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆