hibernate-search | Hibernate Search : full-text search for domain model | Object-Relational Mapping library

You're probably using Hibernate Search 5.x. In Hibernate Search 5.x, the Elasticsearch integration was experimental and only compatible with Elasticsearch up to version 5.6.

The fact that your application was working fine with Elasticsearch 6.8 was pure luck: Hibernate Search 5.x was never intended to work with Elasticsearch 6+.

To upgrade to a more recent version of Elasticsearch, you must upgrade to Hibernate Search 6.0 (or later). The API is different, but there is a very detailed migration guide, and at least you will get production-ready (non-experimental) Elasticsearch integration (plus tons of improvements).

Note that Hibernate Search 6.x also requires upgrading to Hibernate ORM 5.4; see this compatibility matrix.

My guess would be that the user running your application isn't allowed to create directory /data/index. You should probably create it before starting your application, and make sure it's accessible to the user running your application.

Booleans are still indexed as strings in Hibernate Search 5. See org.hibernate.search.bridge.builtin.BooleanBridge. So boolean fields are not part of the problem here.

If you really want to create numeric queries yourself, in Hibernate Search 5 you will have to use numeric range queries, e.g.:

As explained here, the compatibility matrix gives you the compatibility of Hibernate Search with Elasticsearch server.

Elastic seems completely fine with introducing breaking changes in their client JARs; sometimes even in minor versions. As a result, any library that depends on these JARs (e.g. Hibernate Search) needs to target one and only one version of these JARs. Hibernate Search cannot be made compatible with multiple client JARs whose method definitions are different; at least not without a significant maintenance burden that I'm not ready to accept.

Long story short: don't try to override the version of the client JAR used by Hibernate Search; that can't end well. It would be like savagely downgrading your application to JPA 1.0 JARs; it's unlikely to work.

That being said, the new low-level REST client JARs are compatible with older Elasticsearch server versions. So you can use Elasticsearch low-level REST Client 7.10 with Elasticsearch server 5.6.

So you can migrate this way:

1. Upgrade the client in your application to version 7.10 (while staying on Elasticsearch server 5.6).
2. Add Hibernate Search 6.0 to your application.
3. Some time later, upgrade to Elasticsearch server 7.10. Preferably soon, because Elasticsearch 5.6 has reached end-of-life a long time ago.

If you're using the high-level client JARs, though... it's only compatible with the same version of the Elasticsearch server, so you will have to migrate to Elasticsearch server 7.10 before you can migrate to Hibernate Search.

application.properties is a Spring Boot configuration file, not a Hibernate Search configuration file. You cannot just dump Hibernate Search properties in there.

Instead, prefix your Hibernate Search properties with spring.jpa.properties., so that Spring Boot passes along the properties to Hibernate ORM, which will pass them along to Hibernate Search. For example:

It's certainly not possible out of the box.

If it ever becomes possible, you won't benefit from all the Envers features such as "get me this entity at this revision". You will simply index all the revisions of each entity, and you will only be able to query (and retrieve) these revisions. That would be queries such as "get all revisions of the entity with id 1 where name contained "some text".

Also, this will not remove the need for audit tables. The indexes will exist in addition to the audit tables.

That being said, I just gave it a try and we could make it possible in Hibernate Search 6 with just a few changes. If you're still interested, you can have a look there: https://hibernate.atlassian.net/browse/HSEARCH-4238

May 19, 2021 upgrade JUnit with 5.7.2_1 still get:

You are using Hibernate Search 5, which is old, with a recent version of Spring.

Hibernate Search 5, being old, depends on an old version of the Elasticsearch client JARs.

Your version of Spring depends on a newer, incompatible version of the Elasticsearch client JARs.

Two solutions:

1. Upgrade to the newer Hibernate Search 6, which will most likely depend on a version of Elasticsearch that is compatible with the one bundled with Spring. Note that just changing the version won't be enough: group IDs, artifact IDs and APIs are different. See the migration guide.

2. OR try to downgrade to an older version of the Elasticsearch client. For example, with Spring Boot:

1. It's Hibernate Search 6 - in Quarkus 1.13, 6.0.2.Final
2. Yes, it should be. Our main testing is now against the latest Open Source version of Elasticsearch but we are still testing 7.11.
3. Hibernate Search handles reads/writes and also hydrate your search data from the database so you should have the MySQL database around. If you are only doing read-only stuff AND only using projections, maybe not having the database around is possible but I don't think it's a supported use case
4. Yes.
5. You will have to implement it yourself, there's nothing built-in.