Spring Data 2022.0 (Turing) Release Notes - spring-projects/spring-data-commons GitHub Wiki
-
Upgrade to Java 17 baseline
-
Upgrade to Spring Framework 6
-
Upgrade to Jakarta EE 10
-
Ahead-of-Time processing and reflection hints for Graal Native Image compilation
-
Observability integration with Micrometer and Micrometer Tracing
-
Refine repository interface arrangement
-
Merge of Spring Data Envers into Spring Data JPA repository
-
Merge of Spring Data R2DBC into Spring Data Relational repository
Details
-
Spring Data Build - 3.0
Spring Data now requires Java 17 as a baseline. All code is being compiled using Java 17 bytecode.
Spring Data now compiles against Jakarta EE 10 and the jakarta. packages instead of javax. (e.g. jakarta.persistence instead of javax.persistence).
Spring Data offers new variants of the CRUD repositories. These return a List for methods that return multiple entities:
-
ListCrudRepository -
ListQuerydslPredicateExecutor -
ListQueryByExampleExecutor
They can be used as a drop-in replacement for the interfaces of same name but without the List prefix.
Sorting repositories no longer extend their respective CRUD repository. If one requires the old behavior one must extend not only the sorting repository, but also the respective CRUD repository explicitly. This was done so the sorting support could easily be combined with the List repositories introduced above.
The affected interfaces are:
-
PagingAndSortingRepositoryno longer extendsCrudRepository -
ReactiveSortingRepositoryno longer extendsReactiveCrudRepository -
CoroutineSortingRepositoryno longer extendsCoroutineCrudRepository -
RxJavaSortingRepositoryno longer extendsRxJavaCrudRepository
In the past, the behavior of delete methods that did affect zero rows was different in different modules. We made the behavior consistent following these rules:
-
deleteById(ID id)should not throw an exception when no entity gets deleted. -
delete(T t)should throw aOptimisticLockingExceptionexactly if nothing was deleted and the entity has a version property and no exception otherwise.
The behavior of the various modules should get adopted for the 3.0 release.
We fall back to the canonical constructor when using Java Records, and we cannot disambiguate which constructor to use. This approach aligns with the primary constructor resolution scheme when using Kotlin data classes.
Joda Time and ThreeTenBackport are no longer supported for temporal type conversions and general operations such as auditing. Please use Java’s built-in JSR-310 time types from the java.time package.
RxJava 1 and 2 types are no longer supported when declaring reactive repository declarations. Please use either Project Reactor of RxJava 3 instead.
@SortDefault is now repeatable and can be used multiple times without container annotation. Annotation attributes are evaluated through MergedAnnotations allowing the usage of meta-annotations and leveraging attribute aliasing.
API that was removed:
-
EntityInstantiatorin theo.s.d.convertpackage. Use the entity instantiators in theo.s.d.mapping.modelas replacement. -
PageableExecutionUtilsin theo.s.d.repository.supportpackage. The utility was moved into theo.s.d.supportpackage. -
Removal (or encapsulation) of various deprecated methods or constructors, such as
Lazyconstructor, methods onReactiveWrappersand others.
Spring Data JPA is now built against Hibernate 6. For issues to expect, have a look at this ticket.
When you use an ignoreCase operator, whether that’s with standard finders, JSqlParser, Querydsl, or Query by Example, all will lower the selected column, so you only need to maintain one index. If you currently have an index built for upper, you can either remove it or replace it with a proper one.
This behavior was modified to match that of other Spring Data modules.
Delete operations that receive a version attribute throw an OptimisticFailureException when they delete zero rows.
Otherwise, the NOOP delete gets silently ignored.
Save operations that receive a version attribute throw an OptimisticFailureException when they affect zero rows.
These exceptions are no longer wrapped in a DbActionExecutionException.
Note that save operations that are determined to be an update because the aggregate is not new will still throw an IncorrectUpdateSemanticsDataAccessException if they fail to update any row.
This is somewhat asymmetric to the delete-behavior.
But with a delete the intended result is achieved: the aggregate is gone from the database.
For save operations the intended result is not achieved, hence the exception.
With the introduction of BeforeConvertCallback and BeforeConvertEvent those should have been used for Id generation for new aggregates which don’t get an id from the database. By accident it was still possible to use BeforeSaveCallback or the respective event for this purpose. We from now on only support BeforeConvertCallback and BeforeConvertEvent for this purpose.
Spring Data JDBC now does support SpEL expressions in @Query annotations and named queries.
It works just as for Spring Data JPA so you can refer to https://spring.io/blog/2014/07/15/spel-support-in-spring-data-jpa-query-definitions for more details how to use this feature.
Before 3.0. references from entity tables back to their owning entity where based on the entity name, although on might expect the table name to be used.
Starting with 3.0. Spring Data JDBC does indeed use the table name, which might be specified in a @Table annotation as default.
You may control this behaviour by setting the ForeignKeyNaming in the DefaultNamingStrategy.
You may now annotate properties of the aggregate root with @InsertOnlyProperty.
Properties annotated in such way will be written to the database only during insert operations, but they will not be updated afterwards.
Spring Data JDBC now tries to batch SQL operations. If supported by the JDBC driver this should result in fewer roundtrips to the database and therefore better performance for write operations.
Since at the time of the M4 release only snapshot releases of mybatis-spring 2.1 are available we decided to downgrade to 2.0.7. for the M4 release. Unfortunately that release is not compatible with the current milestone of Spring Framework and therefore the MyBatis integration is broken. If you want to use MyBatis with this release, manually add a dependency to mybatis-spring 2.1.0-SNAPSHOT or later.
The build now verifies compatibility against MongoDB Server 6.0 using MongoDB Driver 4.7.
Methods on the MongoTemplate API allowing streaming-oriented result consumption for find and aggregate operations now return a Java 8 Stream to simplify result consumption as a stream. Previously, these methods returned CloseableIterator. Note that the returned Stream must be closed so consumption with try-with-resources can be used in these cases:
try (Stream<Person> stream = mongoTemplate.stream(query, Person.class)) {
// consume stream
}The release provides support for in MongoDB 6 newly added aggregation operators and closes the gap for some missing ones targeting the 5.2 server generation. Operators like $bottom, $bottomN, $firstN, $lastN, $top as well as pipeline stages like $densify and many more are available via dedicated builders in the java API.
DensifyOperation.builder()
.densify("ts")
.range(Range.bounded("2022-08-01", "2021-08-02")
.incrementBy(1)
.unit(HOUR)).build();Getting insights from an application component about its operations, timing, and relation to application code is crucial to understand latency. Spring Data MongoDB ships with a Micrometer instrumentation for the MongoDB driver to collect observations during MongoDB interaction. Once the integration is set up, Micrometer will create meters and spans (for distributed tracing) for each MongoDB operation.
The CassandraMappingContext bean is now renamed to cassandraMappingContext from previously cassandraMapping for a consistent naming scheme across all Spring Data modules. This change is also reflected when using the XML Namespace configuration.
We now provide a CompletableFuture-based asynchronous Template API for CQL and entity operations. The ListenableFuture-future API is now deprecated and moved to legacy subpackages for easier migration.
Getting insights from an application component about its operations, timing, and relation to application code is crucial to understand latency. Spring Data Cassandra ships with a Micrometer instrumentation for the Cassandra driver to collect observations during Cassandra interaction. Once the integration is set up, Micrometer will create meters and spans (for distributed tracing) for each Cassandra query.
As of Spring Data 2022.0.0-RC1 (Turing-RC1) / 3.0.0-RC1, the Spring Data for Apache Geode (SDG) module has been removed from
the Spring Data BOM and Spring Data release train. SDG will no longer continue in the 3.0 generation from this point forward.
See the NOTICE posted on the Spring Data for Apache Geode (SDG) GitHub project page for more details.
The following summarizes the changes in SDG 3.0, which include, but is not limited to:
-
Enhanced support for Locator Security; Issue #621.
-
Enables users to explicitly declare and register types when using PDX serialization; Issue #619.
-
Upgrades to a Java 17 baseline.
-
Upgrades to a Jakarta EE 9 baseline; Issue #539.
-
Upgrades to Apache Geode
1.15; Issue #604. -
Upgrades to Apache Shiro
1.9.1; Issue #605. -
Upgrades to Micrometer
1.10; Issue #607.
All these features will be present in the new SDG 2.8 version.
Getting insights from an application component about its operations, timing, and relation to application code is crucial to understand latency. Spring Data Redis ships with a Micrometer instrumentation for the Lettuce driver to collect observations during Redis interaction. Once the integration is set up, Micrometer will create meters and spans (for distributed tracing) for each Redis command.
Provide read/write customization hooks for GenericJackson2JsonRedisSerializer and Jackson2JsonRedisSerializer
Both Jackson serializers can now be customized with reading and write functions to allow for improved serialization behavior. A use-case for customization is to use JSON views for serialization to limit the properties to serialize.
GenericJackson2JsonRedisSerializer serializer = new GenericJackson2JsonRedisSerializer(new ObjectMapper(),
JacksonObjectReader.create(), (mapper, source) -> {
return mapper.writerWithView(…).writeValueAsBytes(source);
});We’ve upgraded to Jedis 4 as part of the dependency revision. Jedis 4 has reorganized its package structure, so an upgrade required breaking changes within the Jedis integration components. Jedis 4 imposes a limitation: Pipelining can no longer be used together with transactions. Code can either use pipelining or transactions but not both. The documentation contains details regarding Feature Availability across Redis Connectors.
For quite a while we planned to deprecate our own org.springframework.data.redis.connection.RedisZSetCommands.Range type in favor of Spring Data Commons' Range type to avoid code duplications. We also had several types such as Aggregate or Tuple that were heavily bound to RedisZSetCommands while these were also used in other parts of the framework. We refactored some of the types to top-level types and updated existing method signatures.
We also removed long-deprecated code such as LettucePool, the Version type, and AuthenticatingRedisClient. You can find details about the deprecated classes and their replacement in the reference documentation.
-
M1 - Jan 14, 2022
-
M2/M3 - Mar 18, 2022
-
M4 - May 13, 2022
-
M5 - Jul 15, 2022
-
M6 - Sept 16, 2022
-
RC1 - Oct 14, 2022
-
GA - Nov 18, 2022
-
OSS Support until: 24 Nov 2023
-
End of Life: 24 Feb 2025