Spring Data 2024.1 Release Notes

General Themes

Revise JPA Query Enhancer
Add keyspace qualification for Cassandra tables and user-defined types

Participating Modules

Details

Spring Data Build - 3.4
Spring Data Commons - 3.4
Spring Data JPA - 3.4
Spring Data Relational - 3.4
Spring Data MongoDB - 4.4
Spring Data Neo4j - 7.4
Spring Data Elasticsearch - 5.4
Spring Data Couchbase - 5.4
Spring Data for Apache Cassandra - 4.4
Spring Data Redis - 3.4
Spring Data REST - 4.4
Spring Data KeyValue - 3.4
Spring Data LDAP - 3.4

New and Noteworthy

Spring Data Commons - 3.4

Repository Fragments SPI

By default the Spring Data infrastructure only auto-detects fragments, custom extensions to a repository interface, within the repositories base-package. Therefore, fragments residing in another location or contributed by an external archive will not be found if they do not share a common namespace.
New in 3.4, spring.factories allows you to circumvent this restriction by providing both, fragment interface and implementation data as outlined in the following example.

package com.acme.search;

public interface SearchExtension<T> {
    List<T> search(String text, Limit limit);
}

class DefaultSearchExtension<T> implements SearchExtension<T> {
  // ...
}

com.acme.search.SearchExtension=com.acme.search.DefaultSearchExtension

package io.my.movies;

interface MovieRepository extends CrudRepository<Movie, String>, SearchExtension<Movie> {

}

Spring Data JPA - 3.4

SQL and JPQL query parsers were refined for an enhanced QueryRenderer model. Also, the internal organization was refactored to decouple query introspection from actual query rewriting. While there is no change in behavior we were able to reduce parsing overhead significantly.

Spring Data Relational - 3.4

Spring Data MongoDB - 4.4

Spring Data Neo4j - 7.4

Spring Data Elasticsearch - 5.4

Spring Data Couchbase - 5.4

Spring Data for Apache Cassandra - 4.4

Keyspace qualification for tables and user-defined types

@Table and @UserDefinedType now accept a keyspace attribute to use a different keyspace than the CQL session keyspace when interacting with these without the need for intermediate USE <keyspace> statements. This feature can leave the CQL session in the configured keyspace and eliminates the need to run multiple CQL sessions while your application accesses data from a different keyspace.

Additionally, you can configure a KeyspaceProvider for StatementFactory that is used with CassandraTemplate and its asynchronous and reactive variants.

CassandraTemplate template = …;

template.getStatementFactory().setKeyspaceProvider((entity, tableName) -> …);

KeyspaceProvider by default uses the keyspace configured in CassandraPersistentEntity which represents the model of @Table and @UserDefinedType classes.

Refined CQL Specification Entrypoints

We introduced SpecificationBuilder and CqlGenerator as entry points for easier CQL specification discoverability. Previously, specifications were loosely coupled in the specification package. Code that wanted to generate CQL from specifications had to look up the appropriate CQL generator and use it with the specification.

This is much easier now:

CqlSpecification createKeyspace = SpecificationBuilder.createKeyspace("my_keyspace")
		.with(KeyspaceOption.REPLICATION, KeyspaceAttributes.newSimpleReplication())
		.with(KeyspaceOption.DURABLE_WRITES, true);

// results in CREATE KEYSPACE my_keyspace WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true
String cql = CqlGenerator.toCql(createKeyspace);


CreateTableSpecification createTable = CreateTableSpecification.createTable("my_table")
		.partitionKeyColumn("last_name", DataTypes.TEXT)
		.partitionKeyColumn("first_name", DataTypes.TEXT)
		.column("age", DataTypes.INT);

// results in CREATE TABLE my_table (last_name text, first_name text, age int, PRIMARY KEY(last_name, first_name))
String cql = CqlGenerator.toCql(createTable);