I’m happy to announce the latest final release of Hibernate Search:
Hibernate Search 5.5 Final.
We mainly consolidated the features included in the latest candidate release
and worked on fixing some bugs.
As a reminder on versions:
Hibernate Search now requires at least
Hibernate ORM 5.0.0.Final,
and at the time of writing only
Infinispan 8.0.1.Final supports real time replication
Apache Lucene 5.3 index.
<dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search-orm</artifactId> <version>5.5.0.Final</version> </dependency> <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-core</artifactId> <version>5.0.1.Final</version> </dependency> <dependency> <groupId>org.infinispan</groupId> <artifactId>infinispan-directory-provider</artifactId> <version>8.0.1.Final</version> </dependency> <dependency> <groupId>org.apache.lucene</groupId> <artifactId>lucene-core</artifactId> <version>5.3.0</version> </dependency>
Hibernate Search is now able to automatically provide a sensible mapping for
That means that it includes an out of the box
FieldBridge for each of these types, and allows transparent indexing and querying of properties of these types.
You can of course customize the indexing by providing your own
FieldBridge, as usual.
This feature is only available if you are running on a Java 8 runtime, although all other features of Hibernate Search are still backwards compatible with Java 7.
Since Apache Lucene 5.0 (and including 5.3 as we currently require) we can provide a significant performance improvement if you let us know in advance which fields you intend to use for sorting.
For this purpose a new annotation
org.hibernate.search.annotations.SortableField is available.
If you start using this annotation in your projects you’ll benefit from improved performance, but for those who don’t want to update their mapping yet we will fallback to the older strategy.
This subject is discussed in detail in this follow-up post.
@Field(indexNullAs=) to encode some marker value in the index,
the type of the marker is now required to be of a compatible field type as all other values which are indexed in that same field.
This was problematic for `NumericField`s, the ones optimised for range queries on numbers, as we would previously allow you to encode a string keyword like 'null': this is no longer allowed, you will have to pick a number to be used to represent the null value.
As an example for an "age" property you might want to use:
@Field(indexNullAs = "-1") Integer nullableAge;