Removal of deprecated and obsolete types and members. Listeners became obsolete by providing AsynCqlTemplate/AsyncCassandraTemplate as async operations return futures that allow synchronization. Other types are not used anymore.
Replace Flux/Mono.onErrorResumeWith(…) with Flux/Mono.onErrorMap(…) and turn translateException into a method returning a mapping function instead of a Mono emitting the mapped exception.
We now test compatibility with Apache Cassandra's duration type (introduced with Apache Cassandra 3.10). Duration requires a driver version >= 3.2.0 so we drop build profiles against earlier driver versions and use Apache Cassandra 3.10 for integration tests.
Enforce frozen user types in collection types when creating tables and frozen user types when referencing a user type from another type. Previously, the driver returned frozen user-types and no interaction from our side was required. Move user-type specifics to UserTypeUtil.
Introduce compatibility code within the tests to build against different driver versions.
We now support configuration of a CqlTemplate reference when creating CassandraTemplate via XML namespace configuration. Configuring a reference allows reusing an existing CqlOperations instance via CassandraTemplateFactoryBean. Additionally, CassandraTemplateFactoryBean now supports setting a SessionFactory.
<cql:template id="my-cql-template" />
<cassandra:template cql-template-ref="my-cql-template"/>
We now provide a more fine-grained exception translation for exceptions that previously mapped to CassandraUncategorizedException. Existing translation to more specific exception does not change. The following translation rules are introduced by this change:
* OverloadedException and BootstrappingException map to TransientDataAccessResourceException
* NoHostAvailableException, BusyPoolException, ConnectionException, BusyConnectionException map to CassandraConnectionFailureException
* QueryConsistencyException, FunctionExecutionException map to DataAccessResourceFailureException
We now support Session routing with AbstractRoutingSessionFactory. Session routing is based on a map, keyed by a lookup key that is supplied by an implementing class upon Session lookup.
Extend JavaConfig to configure a SessionFactory bean and configure CqlTemplate and CassandraAdminTemplate accordingly.
We now support SessionFactory to obtain Cassandra Session's on a per-request basis. CassandraAccessor is configured primarily with a SessionFactory now, the existing initialization configures a DefaultSessionFactory that returns the initially given Session instance.
Sessions should not be acquired directly by getSession but inside a callback-block so it's guaranteed to operate on the same session within a particular operation. That's especially relevant when preparing and executing prepared statements.
PreparedStatementCallback was changed in a breaking way as it now accepts additionally a Session to retain the session context.
Related ticket: DATACASS-32
Align declared type of CassandraCqlTemplateFactoryBean to CqlTemplate and the type of CassandraTemplateFactoryBean to CassandraTemplate to report consistent bean types. Add JavaDoc.
Original pull request: #76.
Reuse Thread pools during integration test runs to not recreate and dispose Threads multiple times. Increase build and Cassandra memory. Use an external Cassandra instance for TravisCI build jobs.
Revert added features in version 1.0 schema files in favor of version 1.5 schema files. Remove license header. Remove TODOs and fix documentation source names.
We now provide revised CQL and Cassandra templates as central classes to interact with CQL and Cassandra with object mapping. Previously, synchronous and asynchronous methods were exposed inside the same interfaces that made it hard to chose the right method.
The revised Template API consists of:
* CqlTemplate
* AsyncCqlTemplate
* CassandraTemplate
* AsyncCassandraTemplate
CassandraTemplate and AsyncCassandraTemplate reuse CqlTemplate and AsyncCqlTemplate instead of extending from these. This is, to not mix methods using conversion/object mapping with lower level CQL execution methods.
AsyncCqlTemplate and AsyncCassandraTemplate are all new and benefit from ListenableFuture as synchronization aid. They no longer rely on various callback-interfaces.
CassandraTemplate and AsyncCassandraTemplate no longer provide insert/update/delete methods accepting a collection of items. Use CassandraBatchOperations for atomic batches to group operations.
- Remove version placeholders for reactor and rxjava
- Adopt type migration of ReactiveWrappers
- Adopt RxJava to RxJava1 repository interface renaming
- Use ReactiveQueryMethod in ReactiveMongoQuery.
- Remove trailing whitespaces.
- Use ReflectionUtils for method iteration in ReactiveType.
We now support reactive data access with Spring Data Cassandra by adopting Datastax' asynchronous driver.
ReactiveCqlTemplate and ReactiveCassandraTemplate use Project Reactor wrapper types Mono and Flux to implement Template API and repository support. Reactive template supports common operations such as:
* Query/Execution methods for static CQL and prepared statements
* Insert/Save/Update/Delete methods
* Exists and Count projections
* Reactive Callback methods
Person person = new Person("Dave", 25);
template.insert(person) //
.flatMap(p -> template.update(new Person("Sven", 25))) //
.flatMap(p -> template.selectOneById(person.getId(), Person.class)) //
.subscribeWith(TestSubscriber.create()) //
.await() //
.assertValuesWith(result -> {
assertThat(result.getFirstName(), is(equalTo("Sven")));
});
Reactive Repository support is built on top of ReactiveCassandraTemplate using ReactiveCassandraRepository as the store-specific base repository. Reactive repositories are enabled by using @EnableReactiveCassandraRepositories on a @Configuration class to opt-in for reactive support. Reactive repositories can be composed of a reactive base interface such as
* ReactiveCrudRepository
* ReactiveSortingRepository
* RxJava1CrudRepository
* RxJava1SortingRepository
and are identified as reactive repository if one method uses a reactive wrapper type (such as Flux or Observable). If a reactive repository is discovered, it's not implemented by the blocking repository support but with the reactive repository factory. Blocking methods are not (yet) synchronized when using a reactive repository so each repository method must use a reactive wrapper result type. Reactive repository support with Spring Data allows using RxJava1 and Project Reactor types to declare repository methods. Reactive wrapper types are internally converted so the composition library choice on repository level is left up to the user.
There's feature parity between Reactive Cassandra repository support and blocking repository support.
Feature overview:
* Query Methods using String queries and Query Derivation
* Projections
@Configuration
@EnableReactiveCassandraRepositories
class ApplicationConfig extends AbstractReactiveCassandraConfiguration {
@Override
protected String getKeyspaceName() {
return "mykeyspace";
}
@Override
protected String getEntityBasePackages() {
return new String[] {"com.springdata.cassandra"};
}
}
public interface PersonRepository extends ReactiveSortingRepository<Person, String> {
Flux<Person> findByFirstname(String firstname);
Flux<Person> findByFirstname(Publisher<String> firstname);
Mono<Person> findByFirstnameAndLastname(String firstname, String lastname);
}
public interface PersonRepository extends RxJava1SortingRepository<Person, String> {
Observable<Person> findByFirstname(String firstname);
Observable<Person> findByFirstname(Single<String> firstname);
Single<Person> findByFirstnameAndLastname(String firstname, String lastname);
}
We now support Cassandra User-defined types. UDTs can be created using CQL generators and used inside of mapped domain classes. User-defined types can be used either raw as UDTValue that is passed through or as mapped object. Mapped UDTs must be annotated with @UserDefinedType. Types are included into schema generation so known and defined UDTs are created before any tables are created. UDTs can be used with set and list collection types and in primary keys. UDTs can also be used in repository query methods as query predicates.
Updating UDTs will update the whole UDT.
@UserDefinedType
public class Address {
String city;
String country;
}
@Table
public class Person {
@Id String id;
Address address;
UDTValue genericUdt;
}
The XML namespace support was extended with new schema versions to support provide a User Type resolver so UDTs can be resolved:
<cassandra:mapping>
<cassandra:user-type-resolver keyspace-name="${cassandra.keyspace}" />
</cassandra:mapping>
We now rely on Row.getObject(…) to retrieve data from a Cassandra Column. CodecRegistry and ProtocolVersion are configured on Cluster so there's no need to use a static configured CodecRegistry and ProtocolVersion that might not fit the configured values.
High client churn seems to affect Cassandra in a negative way (connection timeouts, driver considers hosts as down). Almost all integration tests bootstrap their own Cluster instance and dispose it once the tests has finished. Identify tests where reuse of a global Cluster instance provided by CassandraRule is possible and switch from context bootstrapping to reuse. This helps to prevent integration test failures.
We now support `NettyOptions` bean references in XML-based configuration.
<bean id="nettyOptions" class="…" />
<cass:cluster contact-points="…" netty-options-ref="nettyOptions" />
Switch heartbeatIntervalSeconds, idleTimeoutSeconds and poolTimeoutMilliseconds to primitive integers and compare values against defaults to decide whether to set these properties on PoolingOptions.
We are now compatible with Datastax’ Cassandra Driver 3.1.1 and support the newly introduced configuration options MaxQueueSize for PoolingOptions.
This change also removes test assertions for PoolTimeoutMillis as this option was deprecated and made unusable with 3.1.1.
