Hibernate Search is a library that integrates Hibernate ORM with Apache Lucene or Elasticsearch by automatically indexing entities, enabling advanced search functionality: full-text, geospatial, aggregations and more. For more information, see Hibernate Search on hibernate.org.

We just published the first stable release of Hibernate Search 6: version 6.0.0.Final.

With more than 900 tickets addressed over the course of 20 alphas and betas, Hibernate Search 6 really is a major release, and it shows.

The most obvious changes: an overhauled API better suited to working with Elasticsearch (but that still works perfectly with embedded Lucene), and upgrades from Lucene 5 to 8 and from Elasticsearch 5.6 to 7.

But it doesn’t stop there: a safer and more concise Search DSL, easier mapping, more powerful bridges, smarter automatic indexing, nested documents, …​

Getting started with Hibernate Search 6

If you want to dive right into the new, shiny Hibernate Search 6, a good starting point is the getting started guide included in the reference documentation.

If you want to migrate an application based on Hibernate Search 5, be aware that Hibernate Search 6 APIs differ significantly from Hibernate Search 5. We recommend you have a look at see the migration guide.

What’s new compared to Hibernate Search 5

Dependency upgrades

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.

Lucene 8

The Lucene backend now uses Lucene 8.7.

Elasticsearch 7

The Elasticsearch backend now works with Elasticsearch 5.6, 6.8 or 7.10. Support for older versions of Elasticsearch was dropped.

API overhaul

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.

Safer, more concise, backend-agnostic Search DSL

The Search DSL is brand new, with several improvements:

  • Search hits now have a type, even when projecting thanks to the brand-new projection DSL.

  • The implementation for numeric predicates (e.g. int-based, long-based, 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
More consistent
  • The API types consistently use the Search prefix: no more mixing FullText with Search or simply no prefix.

  • The SearchQuery type (previously 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 TypeQuery.

Backend-agnostic by default, with backend-specific extensions
More features

Easier mapping

Specialized @*Field annotations

Hibernate Search 6 offers separate @*Field annotations for each major field type: @GenericField works in most cases, but you can access more options (analysis, …​) with @FullTextField, @KeywordField, …​

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
More features
  • Ability to define a searchAnalyzer, to analyze search queries differently from indexed text (useful for auto-complete in particular).

  • Ability to map scaled numbers (BigDecimal/BigInteger) with @ScaledNumberField.

More powerful, backend-agnostic bridges

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.

  • Field declarations do not involve any Lucene API by default.

  • However, bridges can still declare native fields when necessary, be it with Lucene or Elasticsearch.

Easier to configure, smarter automatic indexing

Automatic resolution of reindexing requirements
  • @ContainedIn is no longer needed: when using @IndexedEmbedded on 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 @IndexedEmbedded annotation 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.

More flexible schema management

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.

Runtime joins with nested documents

Hibernate Search 6.0 introduces "nested" fields and predicates, similar to the feature with the same name in Elasticsearch.

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.

And more

  • 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 LazyInitializationException that 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.

  • …​

For a full list of changes since Hibernate Search 6.0.0.CR2, see the release notes.

For a full list of changes since Hibernate Search 5.11, see here.

How to get this release

All details are available and up to date on the dedicated page on hibernate.org.

Feedback, issues, ideas?

To get in touch, use the following channels:

Back to top