In Relation To

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.

Ability to use lambdas for more concise query definition, even when queries are complex.

Simpler syntax for predicates when targeting multiple types in a single query: instantiating multiple QueryBuilders is 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 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.

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.Query for 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.

Injection of native sorts and aggregations within DSL-created Hibernate Search queries.

Ability to directly manipulate the JSON of Elasticsearch requests/responses.

A new id predicate.

A new exists predicate.

Ability to override analyzers on a per-predicate basis.

Better support for multi-valued fields for sorts, projections and aggregations (faceting).

@*Field annotations can be applied directly to List<String> or OptionalInt in 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.

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.

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.

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.

@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.

You can opt out of automatic reindexing locally using @IndexingDependency(reindexOnUpdate = …​).

You can declare the dependencies of a @Transient, indexed property using @IndexingDependency(derivedFrom = …​).