JPA 2 | 获取联接以及我们是否应该使用它们

介绍

最近，我一直在与JPA 2中的FETCH JOINS一起使用，以期从数据库中急切地获取数据，并且我学到了很多关于为什么在日常操作中应避免使用Fetch Joins的知识。

今天的博客文章谈论了我在Fetch上的经历和学习（主要基于当我在查询中有很多FETCH JOINS时获得的评论）。

问题陈述

在我们的项目中，有一种情况是从定义了许多集合值关联的数据库（OneToMany，ManyToMany，也称为ToMany关联）中获取实体。这是实体外观的概念图（为清楚起见，省略了getter和setter）。这是实体的极其简化的示例。在实际情况下，我们大约有11个关联。

public class ItemRecord {@Idprivate String itemId;@Column(name="author")private String author;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private List costs;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private List notes;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private List stats;}

关于上述实体，有几件事需要注意：

它具有3个收藏珍贵的协会。
所有这些关联都被延迟获取，因为JPA中“集合有价值的关联”的默认获取策略是“惰性”。

在我们的业务实现中，我们有一个转换器，该转换器将DAO层返回的值转换为Business DTO。

因此，我们的业务方法的算法如下：

@TransactionAttribute
public List searchItemRecords (SearchCriteria sc) {List ir = itemRecordDao.search(sc);List convertedData = recordConverter.convert(ir);return convertedData;
}

请注意，整个方法都在Transaction内部运行。

每当我们从数据库中获取数据时，就不会急切地获取与成本，统计信息等相关的数据。但是我们的ItemInformation DTO期望所有数据。因此，当首次调用getCosts或getStatistics时，持久性提供程序（在本例中为Hibernate）向数据库激发查询以获取指定的数据。这为我们创建了N + 1个选择查询问题。如果您不熟悉N + 1选择或需要刷新，可以在DZone上查看此文章。

解

我们大多数人，包括我在内，都会选择N + 1选择问题的最快，最简单的解决方案，即使用Fetch Join。在Internet上发布的不同博客/文章中也有很多建议。

因此，我也采用了相同的方法。就我而言，这至少是一种糟糕的方法。

首先让我们看看如何使用FETCH JOIN。

使用Fetch Join之前的查询如下：

SELECT item FROM ItemRecord item WHERE author=:author;

请注意，查询采用JPA形式。

该查询未获取集合值。结果，在翻译器中，当我们对每个ItemRecord执行getCosts时，将触发类似于以下的查询：

SELECT cost FROM Cost where itemId = :itemId

因此，如果我们有3个ItemRecords，则激发到数据库的SELECT查询总数为：

1用于获取所有ItemRecords
3个用于获取每个ItemRecord的成本
3用于获取每个ItemRecord的注释
3个用于获取每个ItemRecord的统计信息

即（3乘3）+ 1

当将其转换为N乘以M +1时，

哪里，

N是找到的主要实体记录的数量
M是主要实体中Collection值关联的数量
1个查询，用于获取所有主要实体

在实际情况下，我们有11个关联。因此，对于每个主要ItemRecord实体，我们将触发11个SELECT查询。激发的查询数量乘以找到的每个ItemRecord。

使得集合值关联成为EAGER是不可行的，因为在实体上运行的许多其他查询仅需要选定的数据。

这不是最佳解决方案。必须做一些事情，很多互联网文章建议使用FETCH JOINS，因为它们最容易实现并解决了（N Time M +1）个查询问题。

因此，我决定在查询中使用FETCH Joins来针对给定场景急切地获取所有数据。

该查询类似于：

SELECT item FROM ItemRecordJOIN FETCH item.costs,
JOIN FETCH item.notes,
JOIN FETCHitem.stats;

跨栏1

我很快意识到，该查询在我的情况下将不起作用，因为我可以拥有一个没有任何与之关联的统计信息的ItemRecord，在这种情况下，上述查询不会向我返回那个ItemRecord（由于ORM的工作方式）因此我将获得不完整的数据。

因此，我接下来转到LEFT JOIN FETCH，即使某些关联关系为空，它也将给我ItemRecord实体返回。查询如下所示：

SELECT item FROM ItemRecordLEFT JOIN FETCH item.costs,
LEFT JOIN FETCH item.notes,
LEFT JOIN FETCH item.stats;

跨栏2

当我运行单元测试以测试上述查询时，出现了异常：

javax.persistence.PersistenceException: org.hibernate.HibernateException: cannot simultaneously fetch multiple bags

问题是什么？

问题是我在实体中使用列表作为集合类型。使用列表会混淆JPA /休眠。 这篇文章很好地记录了这种困惑。

为了解决此问题，我选择使用Set而不是List，主要是因为它是上述博客文章提供的三种解决方案中最简单的方法，并且也很有意义（至少在我实现时）。

因此，我将Entity更改为Set而不是List，并且修改后的实体如下所示：

public class ItemRecord {@Idprivate String itemId;@Column(name="author")private String author;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private Set costs;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private Set notes;@OneToMany(cascade = CascadeType.ALL, mappedBy = "item")private Set stats;}

我再次运行测试用例，并且测试查询的测试用例成功。耶皮但是，我的另一个测试用例的测试用例失败了。看一下测试用例，我意识到我需要按照特定的顺序输入数据，并且使用的是未排序的HashSet。解决方案很简单。使用LinkedHashSet维护元素的顺序。

使用LinkedHashSet可以解决问题，并且我的测试用例通过了。

我很高兴，但我的幸福短暂。