我们刚刚发布了Hibernate Search 6的第一个稳定版本：版本6.0.0.Final。
在20个alpha和beta版本的过程中，我们解决了900多个问题，Hibernate Search 6真的是一个重大版本，并且这一点很明显。
最明显的变化是：经过改进的API，更适合与Elasticsearch协同工作（但仍然可以完美地与嵌入式Lucene协同工作），以及从Lucene 5升级到8和从Elasticsearch 5.6升级到7。
但这并没有结束：更安全、更简洁的Search DSL、更简单的映射、更强大的桥梁、更智能的自动索引、嵌套文档……
与Hibernate Search 5相比的新特性
依赖项升级
- Hibernate ORM
-
Hibernate Search 6依赖于Hibernate ORM 5.4。
请注意，只有 Hibernate ORM 5.4.4.Final 或更高版本才能正确工作；5.4.3.Final 及更早版本将无法正常工作。
API 重构
这可能是 Hibernate Search 6 最重要的一点：大多数 API 都已更改。我们并非轻率地做出这个决定，也不打算在不久的将来再次这么做：在这个阶段，为了使 Hibernate Search 继续改进，破坏 API 是必要的。
这次重构的主要目标是抽象化 Lucene API，以便 Elasticsearch 后端可以成为一等公民，实现时无需任何黑客手段或不必要的依赖。
不言而喻，但 Lucene 后端的重要性将一如既往。实际上，抽象化 Lucene API 对 Lucene 后端也有好处：它将使 Hibernate Search 项目能够在新版本发布后立即升级 Lucene。
重构的另一个好处是：既然 API 必须更改，我们就借此机会实施了长期未完成的改进，这些改进也要求更改 API。请参阅以下部分以了解更多关于这些改进的信息。
更安全、更简洁、后端无关的 Search DSL
Search DSL 是全新的，具有几个改进
- 更安全
-
-
搜索命中现在有类型，即使在投影时也是如此，这得益于全新的 投影 DSL。
-
对于数值谓词（例如基于
int、long、double的）的实现现在是从目标字段的类型确定的，而不是从参数的类型确定。当传递错误类型的参数时，这更安全：Hibernate Search 5 会生成一个不匹配任何内容的谓词，而 Hibernate Search 6 会检测类型不匹配并抛出异常。
-
- 更简洁
-
-
可以使用 lambdas 来更简洁地定义查询，即使查询很复杂 。
-
在单一查询中针对多个类型时，谓词的语法更简单：不再需要实例化多个
QueryBuilders，Hibernate Search 会考虑多个类型被目标，并自动检查目标字段是否在所有目标索引中兼容。
-
- 更一致
-
-
API 类型始终使用
Search前缀：不再混用FullText与Search或没有前缀。 -
现在
SearchQuery类型（之前为FullTextQuery）现在定义了自己的方法，而不是扩展 JPA 的TypeQuery，这突出了它针对索引而不是数据库的事实，并使其成为一个更友好的 API。在必要时，仍然可以 检索一个实现 JPA 的TypeQuery的适配器。
-
- 默认为后端无关，但有后端特定的扩展
-
-
如 API 重构 中所述，Search DSL 默认不再暴露 Lucene 特定的类型。在需要时，仍然可以使用原生 Lucene 查询（见下文）。
-
在 DSL 创建的谓词中注入原生谓词（
org.apache.lucene.search.Query用于 Lucene，JSON 用于 Elasticsearch）。这不是 Lucene 集成的创新，但对于 Elasticsearch 集成来说却是。请参阅 谓词扩展。 -
直接操作Elasticsearch请求/响应的JSON。
-
- 更多功能
更易用的映射
- 专门的
@*Field注解 -
Hibernate Search 6提供了针对每种主要字段类型的单独的
@*Field注解：大多数情况下，@GenericField即可，但您可以通过@FullTextField、@KeywordField等访问更多选项（分析，……）。这样，每个注解只提供所选字段类型有意义的选择，而没有其他选择。您不会再不小心禁用数字字段的索引分析！
- 容器类型映射更简单
- 更多功能
-
-
能够定义一个
searchAnalyzer，以分析搜索查询与索引文本不同（特别是对于自动完成很有用）。 -
能够使用
@ScaledNumberField映射可缩放数字（BigDecimal/BigInteger）。
-
更强大、后端无关的桥接器
新的桥接API不同且大幅改进。
- 对字段定义的完全控制
-
-
桥接器可以精确声明字段类型，特别是可以挑选分析器或在桥接器声明的字段上启用聚合（分面）。
-
针对非String字段的桥接器现在是第一类公民：当在Search DSL中针对桥接器声明的非String字段时，您将不再需要像Search 5中那样绕过桥接器（
.ignoreFieldBridge()）。 -
桥接器可以声明具有精确类型的动态字段，Search DSL将了解这些字段。
-
- 对自动重新索引的完全控制
-
桥接器可以声明它们依赖的属性，使Hibernate Search能够更频繁地重新索引。
- 自定义桥接器注解
-
可以使用自定义注解应用桥接器，允许更清晰的映射，特别是在桥接器参数化时。
有关桥接器的更多信息，请参阅本节文档。
- 后端无关
-
-
字段声明默认不涉及任何Lucene API。
-
然而，在必要时，桥接器仍然可以声明原生字段，无论是使用Lucene还是Elasticsearch。
-
易于配置，更智能的自动索引
- 自动解决重新索引需求
-
-
@ContainedIn不再需要：当在关联上使用@IndexedEmbedded时，Hibernate Search 6会从Hibernate ORM元数据推断关联的逆向方面，这使得它可以在关联的目标更改时自动重新索引带有@IndexedEmbedded注释的类。 -
当无法解决关联的逆向方面时，Hibernate Search 6将在引导时报告映射错误，让您能够提前检测索引不同步的风险。
-
- 轻松覆盖重新索引需求
-
-
您可以使用
@IndexingDependency(reindexOnUpdate = …)本地选择退出自动重新索引。 -
您可以使用
@IndexingDependency(derivedFrom = …)声明@Transient、索引属性的依赖关系。
-
- 轻松配置索引同步
-
有些人希望使用异步自动索引获得更多性能，而其他人更喜欢使用同步自动索引来保证数据安全和索引文档的即时可见性。在Hibernate Search 6中，所有这些都可以通过一个单配置属性进行配置。
- 更智能的变更处理
-
Hibernate Search 6在处理复杂实体图上的变更时更加智能。
当一个实体中的属性发生变化，该实体被多个其他实体索引嵌入时，Hibernate Search 6将仅根据
@IndexedEmbedded(includePaths = …)和其他元数据遍历受变更实际影响的实体关联。
更灵活的架构管理
- 在启动时管理架构
-
与Hibernate Search 5一样，Hibernate Search 6可以在启动时为您管理架构。或者不这样做：如果这会妨碍，则可以禁用。
- 按需管理架构
-
与Hibernate Search 5不同，Hibernate Search 6提供了专门的API来按需触发架构操作。
- 在大量索引时管理架构
-
大量索引器可以自动删除并重新创建架构：您只需调用.dropAndCreateSchemaOnStart(true)。与Elasticsearch后端相比，这可以显著快于从现有架构中删除所有文档。
与嵌套文档的运行时连接
这意味着特别是索引嵌入实体可以搜索得更细致，例如搜索那个作者名字为给定名字，姓氏为给定姓氏的特定书籍。通过适当的映射和查询，Hibernate Search不再会在您搜索“John Doe”时返回由“John Smith”和“Jane Doe”共同撰写的书籍！
有关详细信息，请参阅参考文档中的将嵌入元素结构化为嵌套文档。
如何获取此版本
所有详细信息均可在hibernate.org上的专用页面上找到，并保持最新。
