Spring Data 2024.0 Release Notes

General Themes

Support for Value Expressions
MongoDB 7.0 and MongoDB Java Driver 5.0

Participating Modules

Details

Spring Data Build - 3.3
Spring Data Commons - 3.3
Spring Data JPA - 3.3
Spring Data Relational - 3.3
Spring Data MongoDB - 4.3
Spring Data Neo4j - 7.3
Spring Data Elasticsearch - 5.3
Spring Data Couchbase - 5.3
Spring Data for Apache Cassandra - 4.3
Spring Data Redis - 3.3
Spring Data REST - 4.3
Spring Data KeyValue - 3.3
Spring Data LDAP - 3.3

New and Noteworthy

Spring Data Commons - 3.3

Value Expressions

Spring Data’s support for SpEL Expressions has evolved over the years in alignment with Spring’s expression capabilities. A typical Spring Data module supports expressions in entity- and property-related annotations (such as MongoDB’s @Document("#{tenant.getCollectionName(…)}")), within queries (@Query("SELECT * FROM #{#entityName}")) and constructor arguments (@Value("#root.name")).

There is a bit of inconsistency across variants, and there has been no simple way to include configuration properties from Environment in expressions.

With Value Expressions, we revised the general support for expressions to align closer with Spring Framework’s @Value(…) support for bean expressions. Value Expressions represent either SpEL Expressions, Property Placeholders, or both.

You can use property placeholders alongside SpEL expressions in @Value such as:

@Document("#{tenant.getCollectionName("order")}-${spring.application.name:fallback}")
@Value("#{root.name}")
@Value("${spring.application.name:fallback}")

Value Expressions follow the template style (#{…} for SpEL Expressions, ${…} for Property Placeholders).

Spring Data JPA - 3.3

Spring Data Relational - 3.3

Spring Data MongoDB - 4.3

Upwards Compatibility with MongoDB 5.0 Driver — GH-4578

The MongoDB Java Driver generation 5.0 ships with a couple of new features but also previously deprecated API now removed.
To allow users to upgrade on their own pace the spring-data-mongodb 4.3.x line will remain using the 4.x MongoDB driver while supporting users already upgrading their applications to the new MongoDB bits. This can be easily done by setting the Spring Boot version property for mongodb.version to 5.0.0.
Spring Data MongoDB adapts to changed driver API where possible and will only error for code paths no longer available using the new driver. Compiler warnings for those spots have been in place for several releases already and we strongly recommend to move off deprecated API as soon as possible.

Declarative way for setting MongoDB transaction options — GH-1628

Utilizing @Transactional#label allows to set MongoDB specific attributes for a transaction. By default the mongo: prefix is used to identify applicable labels which may look like the following:

@Transactional(label = { "mongo:readConcern=majority" })

Spring Data Neo4j - 7.3

Explicit transaction boundaries for multi-query operations - GH-2860

Spring Data Neo4j will create explicit transactions around the database operations within the Neo4jTemplate/ReactiveNeo4jTemplate. This avoids confusion around multiple transactions being on the driver level if there are more than one query involved in this operation (e.g. save with relationships or cascading load queries for cyclic entity graphs). Also, this ensures that pure read queries will always be executed in a read-only transaction if nothing else is specified. Every transaction will now also benefit from having the appropriate Spring Data Neo4j app metadata if enabled for better debugging.

There might be scenarios where accidentally custom write queries were issued in a read-only operation, like Neo4jTemplate#findAll. In those cases the operation will need a user-defined write transaction around the method invocation. Either by using @Transactional, an explicit TransactionTemplate for the imperative programming model like here, or the TransactionalOperator for reactive use-cases (example).

(This will also be included in a back-port to 7.2)

Spring Data Elasticsearch - 5.3

Spring Data Couchbase - 5.3

Spring Data for Apache Cassandra - 4.3

Spring Data Redis - 3.3

Spring Data KeyValue - 3.3

Spring Data REST - 4.3

RFC-compliant handling of entities in arrays in merge patches — GH-2358

RFC-7386 requires elements within arrays to completely replace the original data. In previous releases, the patch handling was propagated to nested array elements (originally requested in GH-1294). This was now reverted to properly apply out PUT behavior to such elements. In other words, missing, exposed properties are nulled out. Properties hidden are still kept around.