Hibernate Search 6.0.0.Beta6 是一个重要的测试版本，它引入了许多新特性和改进

“Hibernate Search 6.0.0.Beta6 released”的意思是“Hibernate Search 6.0.0版本的Beta 6发布了”。以下是对这句话以及Hibernate Search 6.0.0.Beta6的详细解析：

• Hibernate Search简介：Hibernate Search是一个将Hibernate ORM与Apache Lucene或Elasticsearch集成的库，它通过自动为实体建立索引，来实现高级搜索功能，如全文搜索、地理空间搜索、聚合等。它能将数据库中实体数据抽取并推送到本地Lucene索引或远程Elasticsearch索引，支持通过注解或API将实体属性映射到索引字段，还能对数据库中所有实体进行按需大规模索引，以及在实体通过Hibernate ORM会话修改时自动实时更新索引，方便开发者构建全文搜索查询并以Hibernate ORM实体形式获取结果。
• Beta 6版本说明：通常软件的Beta版本是在正式发布前的测试版本，目的是让开发者和用户提前体验新功能，同时收集反馈以修复潜在问题。Hibernate Search 6.0.0.Beta6除了包含一些错误修复外，主要引入了以下新特性：
  • 模式管理配置和API：在映射器级别引入了模式管理配置和API，能更好地满足多种使用场景，改进了模式管理，使索引的管理和配置更加灵活和可定制。
  • 多值字段排序：支持对多值字段进行排序，方便在搜索结果中根据多值字段的内容进行排序展示。
  • 更简单和可配置的索引队列：简化了索引队列的设置，并且使其可配置，有助于提高索引数据的效率和性能。
  • 隐式嵌套谓词：引入隐式嵌套谓词，在构建搜索查询时可以更方便地处理嵌套关系和条件。
  • Elasticsearch离线启动：可以在完全离线的模式下启动Hibernate Search，对于一些特定的部署场景和需求提供了便利。
  • 升级依赖：将Lucene升级到8.5版本，Elasticsearch升级到7.6.1版本，Hibernate ORM升级到5.4.13.Final版本，以获得这些组件的新特性和性能改进。

总的来说，“Hibernate Search 6.0.0.Beta6 released”意味着Hibernate Search的开发取得了新进展，该版本为用户提供了更多功能和改进，同时也为最终的稳定版本发布做准备。

Hibernate Search 6.0.0.Beta6 是一个重要的测试版本，它引入了许多新特性和改进。以下是该版本的主要内容解析：

新特性与改进

1. 模式管理配置和 API

   • 在 HSEARCH-3759 和 HSEARCH-3751 中，模式管理功能得到了重新设计，以支持更多用例。
   • 现在可以在映射器级别通过 hibernate.search.schema_management.strategy 配置属性来管理索引/模式，支持多种策略，如 none、create、validate、create-or-validate 等。
   • 默认的自动模式管理策略现在是 create-or-validate，它会创建缺失的索引并验证已存在的索引。

2. 多值字段排序

   • Hibernate Search 现在支持对多值字段进行排序。默认情况下，对于升序排序，会选择每个文档的最小值；对于降序排序，会选择最大值。
   • 新增了 SortMode 方法，允许开发者指定用于排序的值。

3. 更简单和可配置的索引队列

   • 对索引操作的编排进行了改进，支持单个索引的并行索引操作。
   • 默认情况下，Lucene 后端在批量索引时每秒提交一次，而不是之前的每1000个文档提交一次。

4. 隐式嵌套谓词

   • 之前，使用嵌套存储的对象字段时，需要手动为每个子字段的谓词添加嵌套谓词。现在，Hibernate Search 会自动添加嵌套谓词。

5. Elasticsearch 的离线启动

   • 现在可以将 Hibernate Search 配置为完全离线模式启动。这需要配置 Elasticsearch 集群的预期版本，并禁用启动时的版本检查。

6. 依赖升级

   • 升级到 Lucene 8.5.0。
   • 升级到 Elasticsearch 7.6.1。
   • 升级到 Hibernate ORM 5.4.13.Final。

其他改进和错误修复

• 错误处理增强：修复了多个与索引失败报告相关的问题。
• 性能优化：对索引操作进行了优化，提高了数据同步和查询执行的效率。
• 文档改进：更新和完善了官方文档，包括 API 参考和用户指南。

向后兼容性问题

• Lucene 后端中可排序字段的内部 DocValues 格式已更改，如果索引包含可排序字段，则需要重新索引。
• Elasticsearch 索引生命周期管理的配置属性发生了变化。

如何获取该版本

所有详细信息都可以在 Hibernate 官方网站的专门页面上找到。如果需要反馈、报告问题或提出想法，可以通过 Stackoverflow、用户论坛、问题跟踪器或邮件列表与 Hibernate 团队联系。

总体而言，Hibernate Search 6.0.0.Beta6 为开发者提供了更强大的功能和更灵活的配置选项，同时修复了多个问题，提升了性能和用户体验。
Posted by Yoann Rodière | Apr 1, 2020 Hibernate Search Lucene Elasticsearch Releases

We just published Hibernate Search 6.0.0.Beta6.

Aside from several bugfixes, this release mainly introduces schema management configuration and API at the mapper level, sorts on multi-valued fields, simpler and configurable indexing queues, implicit nested predicates, and offline startup for Elasticsearch. It also includes upgrades to Lucene 8.5, Elasticsearch 7.6.1 and Hibernate ORM 5.4.13.Final.
Getting started with Hibernate Search 6

If you want to dive right into the new, shiny Hibernate Search 6, a good starting point is the getting started guide included in the reference documentation.

Hibernate Search 6 APIs differ significantly from Search 5.

For more information about migration and what we intend to do to help you, see the migration guide.
What’s new
Schema management configuration and API

In HSEARCH-3759 and HSEARCH-3751, schema management was revamped in order to address more use cases.

The simpler approach of managing indexes/schemas implicitly, on startup, through a pre-configured strategy, is now configured at the mapper level through the configuration property hibernate.search.schema_management.strategy. Several strategies are available: none, create, validate, create-or-validate, …​ See automatic schema management for more information.

The default strategy for automatic schema management is now create-or-validate. It will create missing indexes and validate pre-existing ones, instead of the previous default that would ignore pre-existing ones and sometimes lead to oversights, some users forgetting to update the schema after changing the Hibernate Search mapping.

A new approach is to manage indexes/schemas explicitly, whenever you want after startup. It involves getting a SearchSchemaManager from Hibernate Search, then calling its methods to create, validate, or even drop the schema on-demand:

SearchSchemaManager manager = Search.mapping( sessionFactory )
.scope( MyEntity.class ) // Use Object.class to target all indexed entity types
.schemaManager();
manager.dropAndCreate();
// Starting here, the freshly created indexes can be used

See manual schema management for more information.

Finally, indexes and schema can simply be dropped and re-created when reindexing, by setting the new dropAndCreateSchemaOnStart(boolean) option on the MassIndexer. See MassIndexer parameters for more information.
Offline startup for the Elasticsearch backend

Thanks to the efforts of Alexis Cucumel (HSEARCH-3841), it is now possible to start Hibernate Search in fully offline mode.

To that end:

Configure the expected version of the Elasticsearch cluster using the property hibernate.search.backends.<backend name>.version, and disable version checks on startup using the property hibernate.search.backends.<backend name>.version_check.enabled.

Disable automatic schema management on startup by setting the property hibernate.search.schema_management.strategy to none.

If necessary, add explicit schema management code to your application that you will trigger when you know the Elasticsearch cluster is up and running.

Sorts on multi-valued fields

As of HSEARCH-3103, Hibernate Search is now capable of sorting on multi-valued fields. By default, the minimum value of each document will be picked for ascending sorts, and the maximum value for descending sorts.

A new mode(SortMode) method in the sort DSL can be used to tell Hibernate Search how to pick the value to sort on:

List hits = searchSession.search( Author.class )
.where( f -> f.matchAll() )
.sort( f -> f.field( “books.pageCount” ).mode( SortMode.AVG ) )
.fetchHits( 20 );

See this section of the documentation for more information.

Thanks to Waldemar Kłaczyński for contributing the implementation.
Implicit nested predicates

Up until now, using the “nested” storage for object fields meant that you had to wrap every predicate accessing one if its sub-fields with a nested predicate, even when there was just one predicate.

As of HSEARCH-3752, Hibernate Search does that for you: nested predicates are now added implicitly when not mentioned explicitly.

This means that this query:

List hits = searchSession.search( Book.class )
.where( f -> f.nested().objectField( “authors” )
.nest( f.match().field( “authors.lastName” )
.matching( “asimov” ) )
.fetchHits( 20 );

… can now be simply written like this (which previously wouldn’t have matched anything):

List hits = searchSession.search( Book.class )
.where( f -> f.match().field( “authors.lastName” )
.matching( “asimov” ) )
.fetchHits( 20 );

If you actually need a condition with more than one predicate on the same nested object, you still need to wrap the predicates in a nested predicate. So this search query will not change:

List hits = searchSession.search( Book.class )
.where( f -> f.nested().objectField( “authors” )
.nest( f.bool()
.must( f.match().field( “authors.firstName” )
.matching( “isaac” ) )
.must( f.match().field( “authors.lastName” )
.matching( “asimov” ) )
) )
.fetchHits( 20 );

Flags in simple query strings

Thanks to the efforts of Waldemar Kłaczyński (HSEARCH-3847), the simple query string predicate can now be configured to enable or disable syntax features as needed:

List hits = searchSession.search( Book.class )
.where( f -> f.simpleQueryString().field( “title” )
.matching( “I want a robot” )
.flags( SimpleQueryFlag.AND, SimpleQueryFlag.OR, SimpleQueryFlag.NOT ) )
.fetchHits( 20 );

Simpler, configurable indexing queues

Indexing in Hibernate Search involves pushing operations to queues, and executing these operations in background threads.

In HSEARCH-3575, several new configuration options were introduced regarding the background threads (Lucene, Elasticsearch) and the queues (Lucene, Elasticsearch).

In HSEARCH-3822 and HSEARCH-3872, we implemented several improvements to the orchestration of indexing operations, enabling parallel indexing for a single index in particular, and generally simplifying the code.

Finally, in order to make the most of parallel indexing, in HSEARCH-3871 we switched the default configuration of commits in the Lucene backend: commits are now performed every second when mass indexing, instead of the previous behavior of committing every ~1000 documents.
Version upgrades

HSEARCH-3867: Upgrade to Lucene 8.5.0

HSEARCH-3870: Upgrade to Elasticsearch 7.6.1

HSEARCH-3873: Upgrade to Hibernate ORM 5.4.13.Final

Hibernate Search 6 requires ORM 5.4.4.Final or later to work correctly. Earlier 5.4.x versions will not work correctly.
Backward-incompatible changes

The internal docvalues format for sortable fields in the Lucene backend has changed. Re-indexing will be necessary if your index contains sortable fields.

Configuration properties relative to Elasticsearch index lifecycle management have changed:

    The configuration property lifecycle.strategy was removed and will trigger an exception on startup if used. For automatic schema management on startup, see the new schema_management options at the mapper level.

    The configuration property lifecycle.minimal_required_status was renamed to schema_management.minimal_required_status.

    The configuration property lifecycle.minimal_required_status_wait_timeout was renamed to schema_management.minimal_required_status_wait_timeout.

Documentation

A few more features in the Sort DSL are now documented:

Sort order

Behavior on missing values

Other improvements and bug fixes

HSEARCH-3796: @IndexedEmbedded can now be applied multiple times to the same getter/field. You will simply need a different prefix.

HSEARCH-3850: A new tool is available to build property keys when configuring Hibernate Search programmatically. See this section of the documentation for more information.

HSEARCH-3844: Using the simple query string predicate on non-analyzed, non-normalized fields in the Lucene backend no longer triggers a NullPointerException. Thanks to Waldemar Kłaczyński for reporting this.

HSEARCH-3845: Prefix queries generated by the simple query string predicate in the Lucene backend no longer skip normalization of the input text. Thanks to Waldemar Kłaczyński for reporting and fixing this.

HSEARCH-3851/HSEARCH-3852: Multiple problems related to reporting of indexing failures have been solved.

HSEARCH-3857: A ConcurrentModificationException used to be thrown in very specific scenarios when indexing multiple entities with @IndexEmbedded dependencies; this was fixed. Thanks to Alexis Cucumel for reporting and fixing this.

HSEARCH-3859: .desc().missing().last() / .asc().missing().first() on double/float-based fields in the Lucene backend no longer place documents around 0, but place them last/first as was originally intended.

HSEARCH-3861: Elasticsearch search queries no longer needlessly fetch the whole document source when no explicit projection is defined.

HSEARCH-3869: Failure in Elasticsearch bulk works no longer lead to a IndexOutOfBoundsException.

HSEARCH-3874: Applying @IdClass on an entity (even not @Indexed), no longer leads to a NullPointerException when bootstrapping Hibernate Search.

And more. For a full list of changes since the previous releases, please see the release notes.
How to get this release

All details are available and up to date on the dedicated page on hibernate.org.
Feedback, issues, ideas?

To get in touch, use the following channels:

hibernate-search tag on Stackoverflow (usage questions)

User forum (usage questions, general feedback)

Issue tracker (bug reports, feature requests)

Mailing list (development-related discussions)