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 to align 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).

Support for Value Expressions is available for the mapping-metadata annotations for the time being. It will be expanded to annotated Repository @Query methods in a later revision.

Behavior Changes in Offset-based Scrolling

Scrolling behavior using offsets has been aligned with keyset-based scrolling. Both implementations now treat a given ScrollPosition as an exclusive starting point. It is important to start scrolling with the initial position ScrollPosition.offset() or ScrollPosition.keyset() to ensure the first element is included in the result. Scrolling from ScrollPosition.offset(0) will resume scrolling after the first element.

Spring Data JPA - 3.3

Spring Data Relational - 3.3

Spring Data MongoDB - 4.3

Compatibility with MongoDB 5.0 Driver

The MongoDB Java Driver generation 5.0 ships with a couple of new features but also previously deprecated API now removed.
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. To allow users to upgrade on their own pace the spring-data-mongodb 4.3.x line will remain backwards compatible with the 4.x MongoDB driver on a best effort basis. While 5.0 is the new default driver, downgrading can be done by setting the Spring Boot version property mongodb.version to 4.11.1.

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" })

Behavior Changes

AggregationOptions will use server defaults for aggregations by no longer defaulting allowDiskUse to false. (GH-4664)

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

Behavior Changes in Random Key (Cluster)

RedisKeyCommands#randomkey() will no longer randomly visit available servers, returning the first non-null result but return the value, which may be null, obtained via the underlying Redis Driver, see (GH-2889).

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 replace the original data completely. In previous releases, the patch handling was propagated to nested array elements (originally requested in GH-1294). This was now reverted to apply out PUT behavior to such elements properly. In other words, missing, exposed properties are nulled out. Properties hidden are still kept around.