We just published a new candidate release for Hibernate Search: 7.0.0.CR1.
This release brings in particular compatibility with Hibernate ORM’s discriminator-based multi-tenancy, compatibility with Elasticsearch 8.10 and OpenSearch 2.10/2.11, an upgrade to Hibernate ORM 6.3.1.Final, an upgrade to Lucene 9.8, some Maven artifact renamings, and other bugfixes and improvements.
What’s new
For a summary of all new features and improvements since 6.2, head to the dedicated page on hibernate.org. |
Dependency upgrades
- JDK 11 (reminder)
-
Hibernate Search now requires Java 11 as a baseline and is no longer compatible with Java 8.
- Switch to Jakarta EE (reminder)
-
Hibernate Search completely switched to Jakarta EE and is not compatible with Java EE anymore. All of
-orm6
and-jakarta
artifacts from the previous series that provided Hibernate ORM 6 and Jakarta EE compatibility are now unavailable since this compatibility is now provided by the main artifacts.
- Hibernate ORM (HSEARCH-4959)
-
Hibernate Search now depends on Hibernate ORM 6.3.1.Final.
- Lucene (HSEARCH-4982)
-
The Lucene backend now uses Lucene 9.8.
- Elasticsearch (HSEARCH-4946)
-
The Elasticsearch backend works with Elasticsearch 8.10 as well as other versions that were already compatible — except for the following versions whose compatibility was dropped, because they already reached their end of life:
-
5.x/6.x (compatibility already dropped in Hibernate Search 7.0.0.Beta1)
-
7.0-7.9 (newly dropped in HSEARCH-4934)
-
- OpenSearch (HSEARCH-4978/HSEARCH-4993)
-
The Elasticsearch backend works with OpenSearch 2.10 and 2.11 as well as other versions that were already compatible — except for versions 1.0, 1.1 and 1.2 whose compatibility was dropped in HSEARCH-4934, because they already reached their end of life.
- Others
-
-
HSEARCH-4941/HSEARCH-4946/HSEARCH-4958/HSEARCH-4967/HSEARCH-4990/HSEARCH-4994: Upgrade to Elasticsearch client 8.10.4
-
HSEARCH-4957 Upgrade to Jackson 2.15.2
-
HSEARCH-4984 Upgrade to Avro 1.11.3
-
HSEARCH-4992 Upgrade to AWS SDK 2.21.1
-
Compatibility with Hibernate ORM’s discriminator-based multi-tenancy
With HSEARCH-4403,
Hibernate Search can now index Hibernate ORM entities
that take advantage of
discriminator-based multi-tenancy in the database (@TenandId
).
Maven artifact renamings
Some Hibernate Search Maven artifacts have been renamed:
-
HSEARCH-4940 Maven artifacts related to JSR-352 artifacts were renamed to reflect the move to the Jakarta EE specification:
-
hibernate-search-mapper-orm-batch-jsr352-core
was renamed tohibernate-search-mapper-orm-jakarta-batch-core
. -
hibernate-search-mapper-orm-batch-jsr352-jberet
was renamed tohibernate-search-mapper-orm-jakarta-batch-jberet
.
-
-
HSEARCH-4928 The artifact
hibernate-search-mapper-orm-coordination-outbox-polling
was renamed tohibernate-search-mapper-orm-outbox-polling
.
Other improvements and bug fixes
-
HSEARCH-4938: The complement operator (
~
) in regexp predicates is no longer supported. -
HSEARCH-4947: Hibernate Search will no longer fail to boot on Windows in some setups.
Thanks to Gábor Lipták for reporting this and helping test the fix!
-
HSEARCH-4487: The Jakarta Batch Mass Indexing job has been redesigned to mirror more closely the behavior of the
MassIndexer
. As a result, it will no longer fail when indexing entities containing a@IndexedEmbedded
and using MySQL with anidFetchSize
set toInteger.MIN_VALUE
.Thanks to Ivan Kotev for reporting this and helping identify the cause!
-
HSEARCH-4980: Hibernate Search will no longer fail when trying to index entities with composite identifiers in the Jakarta Batch Mass Indexing job.
-
HSEARCH-4969: Fixed a bug caused by a mistake in the Lucene 9 upgrade, where
TextMultiValues
would trigger anIndexOutOfBoundsException
. -
HSEARCH-4983: Fixed a potential concurrency issue in the Lucene backend that could lead to "`LockObtainFailedException`: Lock held by this virtual machine".
-
HSEARCH-4986: The Jakarta Batch Mass Indexing job will no longer fail in the partition mapping stage for some JDBC drivers (DB2, MSSQL, …).
-
HSEARCH-4988: Hibernate Search will no longer fail on startup with a
StackOverflowError
when mapping types that are containers of their own type, such asjava.nio.Path
which implementsIterable<Path>
.Attempting to use default container extraction on such types will fail with a clear explanation, and disabling container extraction or otherwise resolving the infinite recursion will work as expected.
And more. For a full list of changes since the previous releases, please see the release notes.
How to get this release
All details are available and up to date on the dedicated page on hibernate.org.
Getting started, migrating
For new applications, refer to the getting started guide:
For existing applications,
assuming you were already using Hibernate Search 6.2 with -orm6
artifacts,
upgrading to Hibernate Search 7.0 mainly requires
removing the -orm6
suffix from your Hibernate Search dependencies
updating the version numbers (alternatively you can use the BOM),
and of course aligning your other dependencies (e.g. Hibernate ORM), if any.
Information about migration, deprecations and breaking changes is included in the migration guide.
Feedback, issues, ideas?
To get in touch, use the following channels:
-
hibernate-search tag on Stackoverflow (usage questions)
-
User forum (usage questions, general feedback)
-
Issue tracker (bug reports, feature requests)
-
Mailing list (development-related discussions)