Hibernate Search 5.5.1.Final 现已发布！
关于我们最近的 5.5.0.Final 版本的反馈非常好，好消息是没有人报告重大问题，但也有人指出新的排序系统有点限制。
因此，我们一直在努力增强 FieldBridge API，以确保那些实施自己桥接的高级用户能够更好地控制排序方式。
我们还开始了一些工作来提高性能，总体来说，我很自豪地表示，这个 5.5.1.Final 版本包括一些小的内部打磨，但结果带来了可衡量的改进。
排序 & FieldBridge 改进
如果您创建了自定义的 FieldBridge 实现，您现在可以声明字段元数据以从改进的排序性能中受益。
自 Hibernate Search 5.5 版以来，我们建议您通过 @SortableField 注解显式标记哪些字段将用于排序。
这会影响索引并触发查询性能的改进，只要 Hibernate Search 能够理解它可以使用新的更有效的排序策略。
如 Ashot Golovenko 所友好地报告，在实现自定义 FieldBridge 时，没有方法让 Hibernate Search 引擎组件知道哪些自定义创建的字段是有效的排序字段，因此即使您的实现足够聪明，能够适当地索引字段以利用新的排序功能，这也不会在查询时间使用。
这个问题已经通过引入对FieldBridge的扩展来解决：使用org.hibernate.search.bridge.MetadataProvidingFieldBridge可以正确配置元数据。但请注意：这种方法是为高级用户设计的，查询引擎将信任您定义的元数据确实反映了桥接实现写入索引的内容。如果在查询时出现不匹配，则在按未索引字段排序时将抛出运行时异常。
请参阅参考文档中的示例 4.5. 通过自定义字段桥接标记可排序字段。
在测试套件中轻松识别低效的排序操作
虽然Hibernate Search在被迫使用次优排序策略执行查询时会记录警告，但这并不容易发现映射或使用错误。
您现在可以设置此属性
hibernate.search.index_uninverting_allowed = false
这样，您的测试将因合理的异常而失败，而不是仅记录警告。
性能改进
与性能相关的许多内部改进。
最有趣的一点是，现在我们可以在各种索引维护操作中自动跳过评分。这意味着您将看到某些索引写入和更新操作的CPU使用率降低，并且在需要应用某些自动过滤查询时，查询性能也会得到改善，例如缩小实体类型、应用分片相关过滤。
排序操作也得到了改进：现在在空间查询中按距离排序或按评分排序时，我们可以跳过索引非逆转过程。
内存使用量也有所降低！特别感谢Andrej Golovnin诊断并报告了HSEARCH-2029，仅此修复就可以减少我们的永久内存使用。
我们还减少了索引和查询执行期间分配的几个短暂但重量级的对象，总体上这应该可以提高JVM的效率。
性能工作是持续挑战：我很高兴看到非常令人尊重的数字，但我们计划进行更多改进，如果您有分析数据或其他有用的数据要分享，请不要自私，分享它！我们始终乐意进一步改进它。
组件升级
升级了几个组件；最值得注意的是，我们现在使用最新的Apache Lucene版本5.3.1。
-
升级Narayana到5.2.5.Final
-
升级JGroups到3.6.6.Final
-
升级Hibernate ORM到5.0.4.Final
-
升级Apache Lucene到5.3.1
-
升级到Hibernate Commons Annotations 5.0.1.Final
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-search-orm</artifactId>
<version>5.5.1.Final</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>5.0.4.Final</version>
</dependency>
<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
<version>5.3.1</version>
</dependency>如何获取此版本
欢迎反馈！请让我们知道您遇到的问题或建议。
