Hibernate Search 4.0.0 Alpha2 发布

在 Hibernate Search 4 的道路上，我们刚刚发布了 Hibernate Search 4.0.0 Alpha2。它包含了一些常规的bug修复，但也包含了一些有趣的新特性，这些特性是通过在 4 系列中开始的重构实现的。

近似实时搜索

传统上，Lucene 专注于卓越的搜索性能，但索引的写入操作可能会非常昂贵，即使是微小的更改（通过触发段重组）。

在 Hibernate Search 中，每当与事务相关的更改应用于索引时，都需要对索引进行提交，以确保新开始的查询会看到新数据。

利用 Lucene 的新近似实时改进，Hibernate Search 现在可以 搜索未提交的缓冲区，这些缓冲区仍在内存中，避免了昂贵的提交，并允许IndexWriter定期刷新，以满足最佳内存管理需求。请注意，Hibernate Search 仍然确保查询只会看到完全提交的事务（没有脏读）。

要亲自体验这种新的写入性能，需要单个配置行。这难道不是一个升级的好理由吗？

尽管如此，也有一些限制

您不能在使用 Hibernate Search 的 JMS 或 JGroups 集群方法时使用它
您不能在使用 Infinispan 的集群中使用它，但您不需要，因为 Infinispan 是内存中的
索引更改定期刷新，因此在发生崩溃的情况下可能会丢失更新 - 如果发生这种情况，您当然将能够通过重新索引数据库来恢复状态

总结接近实时性：写入速度更快，索引安全性较低（崩溃可能丢失数据），不能在集群中使用

可插拔的IndexManager实现

《接近实时》IndexManager是默认IndexManager的系列中第一个替代实现。您现在可以提供自己的实现并插入任何索引后端；您可以通过覆盖与Lucene索引交互的整个设计。当然，如果您这样做，我们很乐意听听并甚至接受贡献：）

长期请求的功能

这是一个长期请求的功能，您现在可以使用@IndexedEmbedded在基本类型集合上

@Entity
@Indexed
class User {
    [...]
    @IndexedEmbedded
    @ElementCollection
    public Set<String> getNicknames() { return nicknames; }
}

另一个请求的功能：您可以使用与Criteria查询一起使用的全文查询来限制您的结果（即带有where子句）——之前只允许重定义检索策略的criteria查询。然而，在这种情况下，query.getResultSize()不被支持（异常）。您需要使用query.list().size()代替。

混合全文查询和criteria限制在您想基于索引中不存在的数据进一步细化查询时很有用。然而，我们不推荐这种方法，您最好将必要的信息放入全文索引中。