|Java||8, 11 or 12|
|Elasticsearch||5.6 - 6.6|
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 (2019-04-05): 6.0.0.Alpha4.
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 and is not ready for production.
While the core of Hibernate Search 6 is there, there are still a lot of limitations:
Features are partially implemented or simply missing. For example, you cannot index a
BigDecimalproperty yet, you cannot configure custom Lucene directories, and so on.
APIs are not considered stable yet.
The low-level parts of the Lucene backend from Hibernate Search 5 that improve its efficiency haven’t been ported to Hibernate Search 6 yet. This results in obvious performance bottlenecks, such as all the indexing from a multi-threaded application being executed sequentially and without any kind of batching.
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. However, we do not offer all the options that were available in Search 5 (yet). Most of the field types supported in Search 5 are supported in Search 6.
Automatic indexing of ORM entities as they are persisted within a transaction (enabled automatically if Hibernate Search is in your classpath and the entity is mapped).
Mass indexing of ORM entities that are already persisted in database.
Search for ORM entities using their Hibernate Search index, and retrieving managed entities as results. However, we do not offer many options regarding how the entities are retrieved and initialized (yet).
Custom, user-defined type bridges, property bridges or value bridges. However, the API to retrieve information from POJOs is currently quite cumbersome: we know that and will work on a lighter API (see HSEARCH-3297, HSEARCH-3298).
All the predicates available in Search 5, except
moreLikeThis. Additionally, the new
existspredicates were added. See
All the predicates available in Search 5. See
All the projections listed in
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).
The Elasticsearch backend now works with Elasticsearch 5.6 or 6.6. 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 "exists" predicate, the ability to override analyzers on a per-predicate basis, …
Injection of native predicates (
org.apache.lucene.search.Query, JSON for Elasticsearch) within DSL-created predicates. This is not new for the Lucene integration, but it is for the Elasticsearch integration. See
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 understands 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.
If you need to upgrade from a previous series, please refer to the migration guide.
Releases in this series
"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.