|Java||8, 11 or 17|
|Hibernate ORM||5.4 (>= 5.4.4.Final), 5.5 or 5.6|
|Elasticsearch server||5.6 - 7.10|
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.
If you want to start using Hibernate Search, please refer to the getting started guide:
If you need to upgrade from a previous series, please refer to the migration guide:
Latest release announcement (2022-03-17): 6.0.9.Final.
A detailed list of new features, improvements and fixes in this series can be found on our issue tracker.
- Hibernate ORM
Hibernate Search 6 relies on Hibernate ORM 5.4.
Note that only Hibernate ORM 5.4.4.Final or later will work correctly; 5.4.3.Final and earlier will not.
This is perhaps the most important aspect of Hibernate Search 6: most APIs have changed. We didn’t take this decision lightly, and we don’t intend to do this again anytime soon: at this point, breaking APIs was necessary for Hibernate Search to keep improving.
The primary goal of this overhaul was to abstract away Lucene APIs, so that the Elasticsearch backend can become a first-class citizen, implemented without any hacks or unnecessary dependencies.
It goes without saying, but the Lucene backend will remain as important as ever. In fact, abstracting away Lucene APIs is good for the Lucene backend too: it will give the Hibernate Search project the ability to upgrade Lucene as soon as new versions are released.
Another benefit of the overhaul: since APIs had to change anyway, we took that opportunity to implement long-overdue improvements that also required API changes. See the following sections to know more about these improvements.
The Search DSL is brand new, with several improvements:
The implementation for numeric predicates (e.g.
double-based) is now determined from the type of the targeted field, instead of the type of arguments. This is safer when passing arguments with the wrong type: where Hibernate Search 5 would have generated a predicate that doesn’t match anything, Hibernate Search 6 will detect the type mismatch and will throw an exception.
- More concise
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.
- More consistent
The API types consistently use the
Searchprefix: no more mixing
Searchor simply no prefix.
FullTextQuery) now defines its own methods instead of extending JPA’s
TypeQuery, highlighting the fact that it targets an index and not a database, and making it a friendlier API. When necessary, it is still possible to retrieve an adapter that implements JPA’s
- Backend-agnostic by default, with backend-specific extensions
As explained in API overhaul, the Search DSL no longer exposes Lucene-specific types by default. When necessary, native Lucene queries can still be used (see below).
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.
- More features
Hibernate Search 6 offers separate
@*Fieldannotations for each major field type:
@GenericFieldworks in most cases, but you can access more options (analysis, …) with
This way, each annotation offers the options that make sense for the selected field types, and only those options. No longer will you end up disabling analysis on a numeric field!
- Simpler mapping of container types
@*Fieldannotations can be applied directly to
OptionalIntin order to index the "contained" elements, thanks to container extractors.
For more complex types (e.g.
Map<String, Integer>), the container extractor can be selected explicitly.
- More features
The new Bridge APIs are different and vastly improved.
- Full control over field definitions
Bridges can declare field types precisely, allowing in particular to pick an analyzer or to enable aggregation (faceting) on a bridge-declared field.
Bridges targeting non-String fields are now first-class citizens: when targeting bridge-declared, non-String fields in the Search DSL, you will no longer have to bypass bridges (
.ignoreFieldBridge()) like you had to in Search 5.
Bridges can declare dynamic fields with a precise type which the Search DSL will be aware of.
- Full control over automatic reindexing
Bridges can declare the properties they rely on, allowing Hibernate Search to reindex less frequently.
- Custom bridge annotations
Bridges can be applied with custom annotations, allowing clearer mappings, especially when bridges are parameterized.
For more information about bridges, see this section of the documentation.
- Automatic resolution of reindexing requirements
@ContainedInis no longer needed: when using
@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.
When the inverse side of an association cannot be resolved, Hibernate Search 6 will report a mapping error on bootstrap, allowing you to detect risks of out-of-sync indexes early.
- Easy override of reindexing requirements
- Easy configuration of indexing synchronization
Some want more performance with asynchronous automatic indexing, others prefer data safety and immediate visibility of indexed documents with synchronous automatic indexing. With Hibernate Search 6, this can all be configured with a single configuration property.
- Smarter change processing
Hibernate Search 6 is smarter when processing changes on complex entity graphs.
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.
- Manage the schema on startup
Just like Hibernate Search 5, Hibernate Search 6 can manage the schema for you on startup. Or not: if this gets in the way, it can be disabled.
- Manage the schema on demand
Unlike Hibernate Search 5, Hibernate Search 6 offers dedicated APIs to trigger schema operations on demand.
- Manage the schema when mass indexing
The mass indexer can drop and re-create the schema automatically: you only have to call .dropAndCreateSchemaOnStart(true). With the Elasticsearch backend, this can be significantly faster than removing all documents from an existing schema.
This means in particular that indexed-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 mapping and the right query, no longer will Hibernate Search return a book co-authored by "John Smith" and "Jane Doe" when you were looking for "John Doe"!
For details, see Structuring embedded elements as nested documents in the reference documentation.
Better support for traditional JPA batch processes involving a periodic flush/clear: Hibernate Search 6 will buffer the documents to index upon flush(), to avoid the dreaded
LazyInitializationExceptionthat Hibernate Search 5 would trigger.
Better reporting of errors on bootstrap: Hibernate Search will provide more context for each error, and will collect as many errors as possible before stopping.
Releases in this series
Workaround for applications hanging on startup with Spring Boot 2.3+, type parameters for type bridges and property bridges, URI-based configuration for target Elasticsearch hosts, upgrade to Hibernate ORM 5.4.24.Final, Lucene 8.7, Elasticsearch 7.10.
First release candidate for Hibernate Search 6. Compared to Beta11: Batch for Java (JSR-352) integration for the ORM mapper, built-in analyzer definitions for Lucene, total hit count on scrolls, optional path prefix for Elasticsearch, upgrade to Hibernate ORM 5.4.23.Final.
Default analyzer, ReindexOnUpdate.SHALLOW to limit automatic reindexing to same-entity updates only, new implementation for AWS IAM authentication, migration helper for applications moving from Search 5 to Search 6, upgrades to Lucene 8.6.2 and Hibernate ORM 5.4.22.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