|Java||8, 11 or 14|
|Hibernate ORM||5.4 (>= 5.4.4.Final)|
|Elasticsearch||5.6 - 7.9|
Not compatible with your requirements? Have a look at the other series.
See also the Compatibility policy.
Documentation for this specific series can be accessed through the links below:
You can find more documentation for all series on the documentation page.
How to get it
More information about specific releases (announcements, download links) can be found here.
Latest release announcement (2020-09-04): 6.0.0.Beta10.
A detailed list of new features, improvements and fixes in this series can be found on our JIRA instance.
Hibernate Search 6.0 is currently a technology preview.
While the core of Hibernate Search 6 is ready for use in a production environment, there are still some limitations:
APIs are expected to stay stable, but may still change if major implementation issues are detected.
Some of the less frequently used features from Hibernate Search 5 are still missing.
There may still be some performance bottlenecks.
If you encounter problems, be sure to report them: new preview versions are released regularly.
Hibernate Search 6 still relies on ORM 5.4 at the moment, because it requires features that are not yet implemented in ORM 6 (still in development).
Note that only Hibernate ORM 5.4.4.Final or later will work correctly; 5.4.3.Final and earlier will not.
A lot of APIs have been changed, for multiple reasons.
The API types consistently use the
Search prefix: no more mixing
Search or simply no prefix.
SearchQuery type (previously
FullTextQuery) now defines its own methods
instead of extending JPA’s
TypeQuery, allowing for an API that makes more sense considering that an index,
not a database, is being targeted.
It is still possible to create an adapter that implements JPA’s
Hibernate Search APIs now abstract from the Lucene APIs, so that alternative backends such as Elasticsearch can be used without having Lucene on your classpath.
This should also allow us to upgrade the Lucene version more easily: in Search 5, as Lucene was "part of" our APIs, we were severely limited when we wanted to upgrade to a newer Lucene version, because any breaking change in Lucene could mean a breaking change for our users, too. Now that using Lucene APIs is no longer necessary to use Hibernate Search, upgrades should be faster.
The Search DSL is brand new, with several improvements:
Ability to use lambdas for more concise query definition, even when queries are complex.
Type-safe projections thanks to the brand-new projection DSL.
Various new features and improvements such as a new
existspredicate, the ability to override analyzers on a per-predicate basis, …
Injection of native predicates (
org.apache.lucene.search.Queryfor Lucene, JSON for Elasticsearch) within DSL-created predicates. This is not new for the Lucene integration, but it is for the Elasticsearch integration. See predicate extensions.
Simpler syntax for predicates when targeting multiple types in a single query: instantiating multiple
QueryBuildersis no longer needed, Hibernate Search takes into account that multiple types are targeted and automatically checks that targeted fields are compatible across all targeted indexes.
The bridge APIs had to change as part of the API refresh, so we took this opportunity to overhaul bridge APIs to make bridges more powerful.
The new Bridge APIs are completely different, but with a lot of improvements:
Custom (user-defined) bridge annotations, allowing the passing of type-safe parameters, and not just strings.
Better support for dirty checking optimization in bridges (in
TypeBridgein particular), by allowing bridges to declare what parts of the entity they use.
Predicates on non-String fields will work without having to bypass bridges (
.ignoreFieldBridge()) like in Search 5.
In Hibernate Search 6, automatic indexing is easier to configure correctly:
@IndexedEmbeddedon an association, Hibernate Search 6 infers the inverse side of the association from Hibernate ORM metadata, which allows it to automatically reindex the class hosting the
@IndexedEmbeddedannotation when the target of the association changes.
@ContainedInis no longer needed.
When the inverse side of an association cannot be resolved, Hibernate Search 6 will report a mapping error, allowing you to detect risks of out-of-sync indexes early.
You can still opt out of automatic reindexing using
@IndexingDependency(reindexOnUpdate = ReindexOnUpdate.NO). See this section of the documentation.
Hibernate Search 6 is also smarter with reindexing.
When a property changes in an entity that is indexed-embedded in multiple other entities,
Hibernate Search 6 will only traverse associations to entities that are actually
affected by the change, based on
@IndexedEmbedded(includePaths = …) and other metadata.
Hibernate Search 6.0 introduces "nested" fields and predicates, similar to the feature with the same name in Elasticsearch.
This means in particular that embedded entities can be searched much more finely, for example searching for that one book whose author has a given first name and last name. With the right query, no longer will Hibernate Search return a book authored by "John Smith" and "Jane Doe" when you were looking for "John Doe"!
For details, see
@IndexedEmbedded storage type
in the reference documentation.
If you need to upgrade from a previous series, please refer to the migration guide.
Releases in this series
Total hit count threshold, conditional indexing, per-index analyzer definitions for Elasticsearch, better timeouts, upgrades to Lucene 8.6.1, Elasticsearch 7.9.0 and Hibernate ORM 5.4.21.Final
Simpler configuration, scrolling, projections on multi-valued fields, complete documentation, upgrades to Lucene 8.6.0, Elasticsearch 7.8.0 and Hibernate ORM 5.4.19.Final
Entity graphs in search queries, @Indexed becomes inherited, upgrades to Lucene 8.5.2, Elasticsearch 7.7.0 and Hibernate ORM 5.4.17.Final
Better sorts/aggregations on multi-valued/nested fields, dynamic index fields, index metamodel, low-level configuration of the Lucene backend, upgrade to Hibernate ORM 5.4.15.Final
Bugfixes, schema management configuration and API at the mapper level, sorts on multi-valued fields, simpler and configurable indexing queues, implicit nested predicates, offline startup for Elasticsearch, upgrades to Lucene 8.5, Elasticsearch 7.6.1 and Hibernate ORM 5.4.13.Final
Aliases for Elasticsearch indexes, delayed commits and NRT for Lucene, renaming of a few Search DSL methods, upgrades to Lucene 8.4, Elasticsearch 7.6 and Hibernate ORM 5.4.12.Final.
Fixed a performance regression in the Lucene backend, new MassIndexingFailureHandler for custom behavior on failure during mass indexing.
Schema improvements, deep customization of Elasticsearch search requests, more powerful bridge definitions, search query timeouts, upgrades to Lucene 8.3.0, Elasticsearch 7.5 and Hibernate ORM 5.4.10.Final.
Search analyzers, improved background failure handling, upgrades to Elasticsearch 7.4 and Hibernate ORM 5.4.7.Final.
Consistent API expected to remain stable, complete documentation for major features, aggregations.
Correct handling of session flushing and clearing, static sharding, upgrades to Elasticsearch 7.3, Lucene 8.2 and Hibernate ORM 5.4.4.Final
Restored configuration options for entity loading and Lucene index storage, simpler and more powerful bridge APIs, upgrades to Elasticsearch 7.2 and Lucene 8.1
Missing index field type parameters restored, explicit indexing APIs restored, upgrade to Elasticsearch 6.8 and 7.1.
Decent performance for Lucene index access, indexing BigDecimal and BigInteger, less verbose search DSL, configuration of on-commit synchronization for automatic indexing, other bugfixes and improvements.
"indexNullAs" feature restored, API to declare dependencies in bridges, Elasticsearch 6.7 and 7.0, other bugfixes and improvements.
"exists" predicate, DSL converter bypass and analyzer override in predicates, upgrade to Lucene 8, Elasticsearch AWS integration restored, other bugfixes and improvements.
More field types, more predicates, more consistent and less verbose API, other bugfixes and improvements.
Mass indexer, Elasticsearch index lifecycle, efficient work orchestration in Elasticsearch, more projections, shorter annotation names, settings improvements.
Initial implementation: a few field types only, a few predicates/sorts/projections only, sub-optimal work orchestration, minimal documentation.