当前位置: 首页 > 面试题库 >

如何使JPA OneToOne关系变得懒惰

贲宏硕
2023-03-14
问题内容

在我们正在开发的此应用程序中,我们注意到一个视图特别慢。我对视图进行了概要分析,发现即使数据库中只有两个对象要获取,hibernate也执行了一个查询,该查询花费了10秒。所有OneToManyManyToMany关系都是懒惰的,所以这不是问题。在检查实际执行的SQL时,我注意到查询中有80多个联接。

在进一步检查该问题时,我注意到该问题是由实体类的深入层次结构OneToOneManyToOne实体之间的关系引起的。所以,我想,我只是让它们变得懒惰,应该可以解决问题。但是注释@OneToOne(fetch=FetchType.LAZY)@ManyToOne(fetch=FetchType.LAZY)似乎不起作用。要么我得到一个例外,要么然后它们实际上没有被代理对象替换,因此变得懒惰。

有什么想法可以让我工作吗?请注意,我不使用persistence.xml定义关系或配置详细信息,所有操作均以Java代码完成。


问题答案:

首先,对 KLE 的答案进行一些澄清:

  1. 无约束(可为空)的一对一关联是没有字节码检测就无法代理的唯一关联。原因是所有者实体必须知道关联属性应包含代理对象还是NULL,并且由于通常是通过共享PK进行一对一映射,因此无法通过查看其基表的列来确定该属性。无论如何,必须急切地使代理变得毫无意义。这是更详细的说明。

  2. 多对一关联(显然是一对多)不受此问题困扰。所有者实体可以轻松地检查其自己的FK(如果是一对多,则最初会创建空集合代理并按需填充),因此关联可以很懒。

  3. 用一对多替换一对一几乎不是一个好主意。您可以用唯一的多对一替换它,但是还有其他(可能更好)的选择。

Rob H. 有一个有效的观点,但是根据您的模型,您可能无法实现它(例如,如果一对一关联可以 空)。

现在,就原始问题而言:

A)@ManyToOne(fetch=FetchType.LAZY)应该工作正常。您确定查询本身不会覆盖它吗?可以join fetch在HQL中指定和/或通过Criteria
API显式设置获取模式,这将优先于类注释。如果不是这种情况,但您仍然遇到问题,请发布您的课程,查询和生成的SQL,以进行更深入的对话。

B)@OneToOne比较棘手。如果绝对不能为空,请遵循Rob H.的建议,并这样指定:

@OneToOne(optional = false, fetch = FetchType.LAZY)

否则,如果您可以更改数据库(向所有者表添加外键列),请进行更改并将其映射为“ joined”:

@OneToOne(fetch = FetchType.LAZY)
@JoinColumn(name="other_entity_fk")
public OtherEntity getOther()

并在OtherEntity中:

@OneToOne(mappedBy = "other")
public OwnerEntity getOwner()

如果您不能做到这一点(并且不能随心所欲地获取),则字节码检测是您唯一的选择。但是,我必须同意 CPerkins的 意见-如果您有 80
由于渴望OneToOne协会而加入,那么您遇到了更大的问题:-)



 类似资料:
  • 问题内容: 在我们正在开发的此应用程序中,我们注意到一个视图特别慢。我剖析了该视图,并注意到,即使数据库中只有两个对象要获取,也执行了一个查询,该查询花费了10秒。所有和关系都是懒惰的,所以这不是问题。在检查实际执行的SQL时,我注意到查询中有80多个联接。 在进一步检查该问题时,我注意到该问题是由实体类的深入层次结构和实体类之间的关系引起的。所以,我想,我只是让它们变得懒惰,应该可以解决问题。但

  • 问题内容: 使用JPA EntityManager和JPA Query对象,如何覆盖带有注释@OneToMany(fetch = FetchType.EAGER)的对象,以便在查询中延迟获取? 如果我有hibernate的Query对象,则可以让它创建一个条件对象,并使用此对象将获取类型设置为惰性。但是我必须使用JPA Query对象。这个问题有什么解决办法吗? 问题答案: 即使使用本地Hiber

  • 我正在使用教义2来绘制学术时间表。以下是对这些关系的简化观察: 一个类有事件(一对多) 事件具有类型(多对一) 一个事件有一个位置(多对一) 使用

  • @没有复合关系的多通关系可以正常工作: 这执行1SQL查询,仅从Telefoni表中获取一行,持续约10ms。 但是,当添加任何带有复合@JoinColumns的@manytone关系时,延迟抓取将停止工作: 这将执行37个SQL查询,急切地获取每个父实体和每个父实体的父实体,直到解决所有关系。这将持续大约600毫秒。 由于向我的实体添加了一个额外的关系,我的性能下降了60倍...除了更改我的数据

  • 这是一个使用周期性提交20000加载CSV的子句,其标题来自“http://192.3.4.101:8080/export/rel.CSV”作为行匹配(a:person{id:row.id}),(b:place{id:row.place_id})create(a)-[:row.relation_type]->(b) 这主要是图片中的rel.csv文件,用户“create(a)-[:type]->(