Hibernate Search 的内部

对于每个索引类型，构建过程包括创建根 PojoIndexingProcessorOriginalTypeNode 生成器，并将元数据贡献者应用于此生成器（请参阅Bootstrap），并在需要时创建嵌套生成器（例如，当一个元数据贡献者提到 POJO 属性时）。每当找到 @IndexedEmbedded 时，只需递归地将该进程应用于在 @IndexedEmbedded 属性节点下创建的类型节点。

作为一个例子，我们考虑映射模型

类 IndexedEntityClass 已被索引。它有 2 个映射字段，以及一个名为 embedded 的类型为 EmbeddedEntityClass 的属性上的索引嵌入类 EmbeddedEntityClass 有一个映射字段，以及一个名为 secondLevelEmbedded 的类型为 SecondLevelEmbeddedEntityClass 的属性上的索引嵌入类 SecondLevelEmbeddedEntityClass 最后有一个映射字段，以及一个名为 thirdLevelEmbedded 的类型为 IndexedEntityClass 的属性上的索引嵌入。为了避免任何无限递归，索引嵌入的深度最大限制为 1，这意味着它将嵌入直接在 IndexedEntityClass 类型中映射的字段，但不会以传递方式包括任何索引嵌入。

使用以上描述的过程将此模型转换为此节点生成器树

虽然映射模型最初被组织为循环图，但索引处理器节点被组织为树，这意味着它无环。为了以直接的方式在运行时处理实体，而不需要依赖复杂逻辑、可变状态或元数据查找，这是必需的。

从潜在的循环图转换为树是由以下事实引起的，我们“展开”索引嵌入定义，通过为在不同嵌入级别出现的相同类型的多个索引处理器节点创建来破坏循环。

在我们的示例中，IndexedEntityClass 正好是这种情况下：根节点表示此类型，但是底部的类型节点还表示相同的类型，只在不同的嵌入级别上。

最终，创建的索引处理树将遵循与生成器树大致相同的结构。由于优化，索引处理器树与生成器树可能有些不同。具体而言，如果我们检测到节点在运行时不会为文档添加任何内容，一些节点可能会被修剪，当使用具有路径筛选 (includePaths) 或深度筛选 (includeDepth) 的 @IndexedEmbedded 时，这可能发生在一些属性节点上。

在我们的示例中，“embedded”节点底部的情况就是这样。生成器节点在应用和解释元数据时创建，但事实证明该节点没有任何子级也没有任何桥梁。因此，在创建索引处理器时将忽略此节点。

在启动期间，为每个已索引的或包含的类型生成一个重新索引解析器树形结构。构建这些解析器的入口点可能并不明显：它是索引解析器构建过程。事实上，由于我们在给定已索引类型中构建索引处理器，我们将发现索引此类型时在实体关系图中将遍历的所有路径，从而发现已索引类型的索引过程明确地依赖关系。这些就是构建重新索引解析器所需的所有信息。

为了了解重新索引解析器的构建方式，务必记住重新索引解析器镜像索引处理器：如果实体 A 的索引处理器在某个时间点引用实体 B，则可以确定实体 B 的重新索引解析器会在某个时间点引用实体 A。

作为示例，我们来考虑上一节中的索引处理器构建器树 (索引处理器)

当我们构建索引处理器时，我们还将构造另一棵树，以表示从根类型（IndexedEntityClass）到每个依赖的依赖项。这就是依赖项收集器发挥作用的地方。

依赖项收集器的组织方式与索引处理器构建器大致相同，呈树状结构。向根构建器提供根节点，然后为其每个子项创建一个节点，依此类推。在此过程中，每个构建器都能够通知其依赖项收集器它将实际构建一个索引处理器（它不会由于某些优化而被删减），这意味着需要在依赖项树中考虑此节点。这是通过 PojoIndexingDependencyCollectorValueNode#collectDependency 方法完成的，该方法会触发一些其他步骤。

让我们看看我们的依赖项收集器树最终会是什么样子

以红色显示的值节点是我们将使用 PojoIndexingDependencyCollectorValueNode#collectDependency 标记为依赖项的节点。最底部的 embedded 属性将被检测为在索引期间未使用，因此相应的 value 节点将不会标记为依赖项，但所有其他 value 节点都会标记为依赖项。

实际的重新索引解析器构建发生在针对每个值节点调用 PojoIndexingDependencyCollectorValueNode#collectDependency 时。为了了解其工作原理，我们以 longField 的值节点为例。

当这个节点上调用 collectDependency 时，依赖项收集器将首先回溯到最后遇到的实体类型，因为那是 POJO 映射器将接收“更改事件”的类型。一旦找到此实体类型，依赖项收集器类型节点将从一个公用池中检索此类型的重新索引解析器构建器，该公用池在所有索引类型的依赖项收集器之间共享。

重新索引解析器构建器遵循与其构建的重新索引解析器相同的结构：它们是树中的节点，每种类型的重新索引解析器节点都有一个构建器类型：PojoImplicitReindexingResolverOriginalTypeNodeBuilder、PojoImplicitReindexingResolverPropertyNodeBuilder、…​

回到我们的示例，当在 longField 的值节点上调用 collectDependency 时，我们回溯到遇到的最后一个实体类型，依存关系收集器类型节点检索到什么将会成为我们的“根”重新索引解析器节点的生成器

从那里，重新索引解析器生成器传递给下一个依存关系收集器值节点，使用 PojoIndexingDependencyCollectorValueNode#markForReindexing 方法。此方法还将所依存属性的路径作为参数，在本例中为 longField。

然后值节点将使用其对依存关系树的了解（使用其在依存关系收集器树中的祖先）从上一实体类型构建一个 BoundPojoModelPath 到该值。在我们的例子中，此路径为 Type EmbeddedEntityClass ⇒ Property "secondLevelEmbedded" ⇒ No container value extractor。

此路径表示两个实体类型之间的关联：包含方上的 EmbeddedEntityClass 和被包含方上的 SecondLevelEmbeddedEntityClass。为了完成重新索引解析器树，我们需要 **反转** 此关联，即找出从 SecondLevelEmbeddedEntityClass 到 EmbeddedEntityClass 的反路径。此操作在 PojoAssociationPathInverter 中使用 POJO 元模型的表示 中提到的“附加元数据”完成。

反转路径成功后，依存关系收集器值节点可以向重新索引解析器生成器添加新的子项

然后将产生的重新索引解析器生成器传递到下一个依存关系收集器值节点，并且此过程会重复

一旦我们到达依存关系收集器根，我们几乎完成了。重新索引解析器生成器树已经填充了每当 SecondLevelEmbeddedEntityClass 的 longField 属性发生更改时重新索引 IndexedEntityClass 所需的每个节点。

现在唯一要做的是注册所依存的路径（在我们的示例中为 longField）。通过注册此路径，我们将能够建立一个 PojoPathFilter，以便每当 SecondLevelEmbeddedEntityClass 发生更改时，我们将遍历该树，但不是全部树：如果在某个点我们注意到一个节点仅在 longField 发生更改时才相关，但是“变脏状态”告诉我们 longField 并未更改，那么我们可以跳过树的一个分支，从而避免无用的延迟加载和重新索引。

上面的示例故意简单，是为了给出一个关于如何构建重新索引解析器的总体概念。在实际算法中，我们必须处理多种情况，使得整个过程变得更加复杂