|Java||8 - 11|
|Elasticsearch||5.6 - 6.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 (2018-11-29): 6.0.0.Alpha1.
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
Doubleproperty yet, you cannot configure custom Lucene directories, you cannot ignore bridges in the predicate DSL, and so on.
APIs are not considered stable yet.
The low-level parts of 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 works from a multi-threaded application being executed one after another and without any form 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), and we do not support all the data types (yet).
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).
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 listed in
org.hibernate.search.engine.search.dsl.predicate.SearchPredicateFactoryContext. However, we do not offer all the options that were available in Search 5 (yet).
All the sorts listed in
org.hibernate.search.engine.search.dsl.sort.SearchSortContainerContext. However, we do not offer all the options that were available in Search 5 (yet).
All the projections listed in
org.hibernate.search.engine.search.dsl.projection.SearchProjectionFactoryContext. However, we do not offer all the options that were available in Search 5 (yet).
Hibernate Search 6 still relies on ORM 5.3 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.5. Support for older versions of Elasticsearch was dropped.
A lot of APIs have been changed, for multiple reasons.
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.
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
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
Initial implementation: a few field types only, a few predicates/sorts/projections only, sub-optimal work orchestration, minimal documentation.