|Java||8, 11 or 13|
|Hibernate ORM||5.4 (>= 5.4.4.Final)|
|Elasticsearch||5.6 - 7.5|
Not compatible with your requirements? Have a look at the other series.
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-01-23): 6.0.0.Beta4.
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 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.
The exact features that are currently implemented and expected to work will be added to the reference documentation as new Alpha versions are released, but to sum up, here is what you can start to play with:
Mapping of entities using either annotation mapping or programmatic mapping. Most of the field types supported in Search 5 are supported in Search 6. See mapping in the reference documentation.
Custom, user-defined type bridges, property bridges or value bridges. See bridges in the reference documentation.
Automatic indexing of ORM entities on transaction commit or session flush (if outside of a transaction) (enabled automatically if Hibernate Search is in your classpath and the entity is
@Indexed). See automatic indexing in the reference documentation.
Mass indexing of ORM entities that are already persisted in database. See mass indexing in the reference documentation.
Searching for ORM entities using their Hibernate Search index, and retrieving managed entities as results. See query DSL in the reference documentation.
All the predicates available in Search 5, except
moreLikeThis. Additionally, the new
existspredicates were added. See predicate DSL in the reference documentation.
All the sorts available in Search 5. See sort DSL in the reference documentation.
All the projections available in Search 5. See projection DSL in the reference documentation.
Aggregations, equivalent to the "faceting" feature of Search 5. See aggregation DSL in the reference documentation.
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.
The Elasticsearch backend now works with Elasticsearch 5.6, 6.8 or 7.3. Support for older versions of Elasticsearch was dropped.
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 to pass 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.
Automatic indexing improvements are not limited to bridges:
@IndexedEmbedded is easier to configure properly in Search 6, too.
To be precise, changes on indexed-embedded entities trigger reindexing of the "embedding" entity automatically,
and annotating the inverse side of the association with
@ContainedIn is no longer needed in most cases.
A mapping error will be reported when the inverse side of the association cannot be resolved.
Hibernate Search 6.0 introduces "nested" fields and predicates, similar to the feature with the same name in Elasticsearch.
@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
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.