使用JPA和Hibernate加载没有N + 1笛卡尔积的递归对象图
将项目从Ibatis转换为JPA 2.1时，我遇到了一个问题，我必须为一组对象加载一个完整的对象图，而不是出于性能原因而没有按N + 1选择或使用笛卡尔积。
用户查询将产生List ，我需要确保在返回任务时，它们已填充所有属性，包括父 ， 子 ， 依赖项和属性 。 首先让我解释一下所涉及的两个实体对象。
任务是层次结构的一部分。 它可以有一个父任务，也可以有子。 任务可以依赖于其他任务，由’dependencies’属性表示。 任务可以有许多属性，由properties属性表示。
尽可能简化了示例对象，并删除了样板代码。
@Entity public class Task { @Id private Long id; @ManyToOne(fetch = LAZY) private Task parent; @ManyToOne(fetch = LAZY) private Task root; @OneToMany(mappedBy = "task") private List properties; @ManyToMany @JoinTable(name = "task_dependency", inverseJoinColumns = { @JoinColumn(name = "depends_on")}) private List dependencies; @OneToMany(mappedBy = "parent") private List children; } @Entity public class TaskPropertyValue { @Id private Long id; @ManyToOne(fetch = LAZY) private Task task; private String name; private String value; } 给定任务的任务层次结构可以无限深，因此为了更容易获得整个图形，任务将通过“root”属性指向它的根任务。
在Ibatis中，我只是获取了根id的不同列表的所有任务，然后使用“task_id IN（）”查询对所有属性和依赖项进行了即席查询。 当我有这些时，我使用Java代码向所有模型对象添加属性，子项和依赖项，以便图形完整。 对于任何大小的任务列表，我只会做3个SQL查询，而我正在尝试用JPA做同样的事情。 由于’parent’属性指示添加子项的位置，因此我甚至不必查询这些。
我尝试了不同的方法，包括：
让延迟加载做它的工作
- 表现自杀，无需详细说明:)
JOIN FETCH子节点，JOIN FETCH依赖节点，JOIN FETCH属性
- 这是有问题的，因为产生的笛卡尔积很大，而我的JPA实现（Hibernate）不支持List，只有在获取多个包时才设置。 任务可能具有大量属性，使得笛卡尔产品无效。
Ad-hoc查询方式与我在ibatis中的方式相同
- 我不能将子，依赖项和属性添加到Task对象上的Lazy初始化集合，因为Hibernate将尝试将它们添加为新对象。
一种可能的解决方案可能是创建不受JPA管理的新Task对象，并使用这些对象将我的层次结构缝合在一起，我想我可以忍受它，但它感觉不是非常“JPA”，然后我不能使用JPA擅长 – 自动跟踪和持久更改我的对象。
任何提示将不胜感激。 如果有必要，我愿意使用供应商特定扩展。 我使用Hibernate 4.3.5.Final在Wildfly 8.1.0.Final（Java EE7 Full Profile）中运行。
可用选项
有一些策略可以实现您的目标：
-
sub-select fetching将使用额外的子选择加载所有延迟实体，这是您第一次需要该给定类型的延迟关联。 这个声音起初很吸引人，但它使你的应用程序易于获取额外的子选择实体的数量，并可能传播到其他服务方法。
-
批量提取更容易控制，因为您可以在一个批处理中强制实施要加载的实体数量，并且可能不会影响太多其他用例。
-
如果您的数据库支持，则使用递归公用表表达式 。
未雨绸缪
最后，所有关于您计划对所选行进行的操作都是如此。 如果只是将它们显示在视图中， 那么本机查询就足够了 。
如果您需要在多个请求中保留实体（首先是视图部分，第二个是更新部分），而不是实体是更好的方法。
根据您的响应，我发现您需要发出EntityManager.merge()并且可能依赖级联来传播子状态转换（添加/删除）。
因为我们正在谈论3个JPA查询，并且只要你没有获得笛卡尔积，那么你就应该使用JPA。
结论
您应该争取最少量的查询，但这并不意味着您将始终必须只有一个查询。 两个或三个查询根本不是问题。
只要您控制查询号码并且没有进入N + 1查询问题，您也可以使用多个查询。 交易一个笛卡尔积（2个一对多的提取）进行一次连接和一次额外选择是一个很好的交易。
最后，您应该始终检查EXPLAIN ANALYZE查询计划并强化/重新考虑您的策略。