DATACMNS-836 - Add components to support reactive repositories. #177

mp911de · 2016-09-21T14:27:10Z

We now expose reactive interfaces to facilitate reactive repository support in store-specific modules. Spring Data modules are free to implement their reactive support using either RxJava1 or Project Reactor (Reactive Streams). We expose a set of base interfaces:

ReactiveCrudRepository
ReactiveSortingRepository
RxJava1CrudRepository
RxJava1SortingRepository

Reactive repositories provide a similar feature coverage to blocking repositories. Reactive paging is not supported.

A store module can choose either Project Reactor or RxJava 1 to implement reactive repository support. Project Reactor and RxJava types are converted in both directions allowing repositories to be composed of Project Reactor and RxJava query methods. Reactive wrapper type conversion handles wrapper type conversion at repository level. Query/implementation method selection uses multi-pass candidate selection to invoke the most appropriate method (exact arguments, convertible wrappers, assignable arguments).

We also provide ReactiveWrappers and ReactiveWrapperConverters to expose metadata about reactive types and their value multiplicity.

Related ticket: DATACMNS-836

Open issues:

Revisit changes
Remove touched classes without functional changes

mp911de · 2016-10-28T14:30:36Z

QueryExecutionConverters uses ReactiveAdapterRegistry which requires Project Reactor to be available on the classpath. This breaks applications not having Project Reactor on their class path.

mp911de · 2016-10-31T18:11:22Z

src/main/java/org/springframework/data/repository/reactive/RxJavaCrudRepository.java

+	/**
+	 * Deletes all entities managed by the repository.
+	 */
+	Single<Void> deleteAll();


Consider Completable instead of Single<Void>

mp911de · 2016-10-31T18:12:02Z

src/main/java/org/springframework/data/repository/reactive/RxJavaCrudRepository.java

+	 * @return the entity with the given id or {@literal null} if none found
+	 * @throws IllegalArgumentException if {@code id} is {@literal null}
+	 */
+	Single<T> findOne(Single<ID> id);


Consider Observable<T> instead of Single<T> as the result may be absent.

Upgraded to Spring Data Build parent 2.0 snapshots. Removed obsolete distribution key property. Removed obsolete template.mf.

Added explicit generics invocations in places that caused an ambiguous invocation on Java 8.

…strar.

Prepare issue branch.

We now expose reactive interfaces to facilitate reactive repository support in store-specific modules. Spring Data modules are free to implement their reactive support using either RxJava 1 or Project Reactor (Reactive Streams). We expose a set of base interfaces: * `ReactiveCrudRepository` * `ReactiveSortingRepository` * `RxJava1CrudRepository` * `RxJava1SortingRepository` Reactive repositories provide a similar feature coverage to blocking repositories. Reactive paging support is limited to a `Mono<Page>`/`Single<Page>`. Data is fetched in a deferred way to provide a paging experience similar to blocking paging. A store module can choose either Project Reactor or RxJava 1 to implement reactive repository support. Project Reactor and RxJava types are converted in both directions allowing repositories to be composed of Project Reactor and RxJava 1 query methods. Reactive wrapper type conversion handles wrapper type conversion at repository level. Query/implementation method selection uses multi-pass candidate selection to invoke the most appropriate method (exact arguments, convertible wrappers, assignable arguments). We also provide ReactiveWrappers to expose metadata about reactive types and their value multiplicity.

…a 2 type conversion.

- Rename RxJava...Repository to RxJava1...Repository - Use Completable and Observable instead of Single for results without values/optional values - Remove reactive paging for now as it does not really fit reactive data streaming - Expose ReactiveWrappers.isAvailable(ReactiveLibrary) method to query library availability

…verters. Move reactive wrapper conversion to ReactiveWrapperConverters to minimize touching points with reactive APIs. ReactiveWrapperConverters is used only from reactive repository components and does not initialize with blocking API use. This removes the need of having Project Reactor on the class path for non-reactive use.

…blisherAdapter keep state between multiple subscribers.

odrotbohm

A couple of comments regarding the use of a ConversionService for distinguishing between reactive and non-reactive repositories. I'll push a commit with some suggested changes into the PR.

odrotbohm · 2016-11-13T13:28:03Z

...java/org/springframework/data/repository/config/RepositoryConfigurationExtensionSupport.java

@@ -293,16 +294,14 @@ protected boolean isStrictRepositoryCandidate(Class<?> repositoryInterface) {
 	 * @param loader must not be {@literal null}.
 	 * @return the repository interface or {@literal null} if it can't be loaded.
 	 */
-	private Class<?> loadRepositoryInterface(RepositoryConfiguration<?> configuration, ResourceLoader loader) {
+	protected Class<?> loadRepositoryInterface(RepositoryConfiguration<?> configuration, ResourceLoader loader) {


What's the reason we need to make this protected?

Module-specific implementations need to load the interface for type usage introspection (see MongoRepositoryConfigurationExtension.getRepositoryConfigurations(…)/ReactiveMongoRepositoryConfigurationExtension.getRepositoryConfigurations(…)). The requirement derives from distinguishing between blocking/reactive repository interfaces.

odrotbohm · 2016-11-13T15:54:39Z

src/main/java/org/springframework/data/repository/core/support/RepositoryFactorySupport.java

+			repositoryInformation = new DefaultRepositoryInformation(metadata, repositoryBaseClass,
+					customImplementationClass);
+		} else {
+			// TODO: Not sure this is the best idea but at some point we need to distinguish between


What if we introduced a method on ReactiveWrappers that indicates whether a method uses a reactive wrapper type (either parameter or return type) or even a class is using one (by inspecting all methods exposed). That in place we could call that very method here. That way, we could at least keep the creation of the ConversionService inside that class and move away from that rather indirect decision.

On a second thought… we could even expose ….isReactiveRepository() on RepositoryMetadata backed by the same logic.

odrotbohm · 2016-11-13T16:56:33Z

src/main/java/org/springframework/data/repository/reactive/ReactiveCrudRepository.java

+	 * @return the saved entities
+	 * @throws IllegalArgumentException in case the given {@code Publisher} is {@literal null}.
+	 */
+	<S extends T> Flux<S> save(Publisher<S> entityStream);


Should we rather use a Flux as parameter here, too. If not, should findOne(…) use an Observable? Otherwise there's an asymmetry between the parameter types, right?

The root cause for asymmetry are design differences between RxJava and Project Reactor. There's no common base type for RxJava types whereas Reactor uses Publisher. Publisher is a general purpose type where multiplicity does not matter. RxJava enforces a specific type. Accepting Publisher is the recommended way to maximize interop between reactive libraries.

We can reduce asymmetry by reducing methods. findOne can be invoked also with findAll(mono) or findAll(single.toObservable()) which allows us to reconsider our API surface.

RepositoryMetadata now exposes an ….isReactiveRepository() that's implemented by inspecting the backing repository interface for any reactive wrapper type appearing in method signatures. That allows us to move down the use of a ConversionService down to ReactiveRepositoryInformation.WrapperConversionMatch. Made a couple of methods static that could be. Simplified some logic using streams. A bit better wording in assertions. Some formatting when using streams.

odrotbohm · 2016-11-13T17:58:41Z

I pushed the changes suggested above in abac726. The use of a ConversionService still seems to be a bit of overkill in WrapperConversionMatch as I guess we could just determine the same information from ReactiveWrappers directly.

RepositoryConfigurationExtensionSupport now exposes a ….useRepositoryConfiguration(RepositoryMetadata) so that extensions can opt in or out of an interface taking part in configuration more easily. Turned loadRepositoryInterface(…) private again as extensions should be able to just inspect the RepositoryMetadata now. Some parameter rename in ReactiveWrapperConverters to avoid confusion.

Introduced ReactiveRepositoryFactorySupport so that validation for the presence of all required converters (e.g. RxJava 1) does not have to be repeated in individual stores.

…rConverters. Reactive type conversion now happens fully inside of ReactiveWrapperConverters and does not require an external ConversionService. This change allows changes to reactive type conversion without changing the API since all details are encapsulated by ReactiveWrapperConverters.

Fixes spring-projectsgh-175 (more of a workaround really and spring-projectsgh-177 is still open to track further changes).

Fixes spring-projectsgh-177

mp911de mentioned this pull request Sep 26, 2016

DATAMONGO-1176 - Add support for reactive data access. spring-projects/spring-data-mongodb#393

Closed

odrotbohm force-pushed the issue/DATACMNS-836 branch from 8cd82a8 to 3f01027 Compare September 27, 2016 16:52

odrotbohm force-pushed the 2.0.x branch from 4637a36 to e240852 Compare October 10, 2016 11:09

odrotbohm force-pushed the issue/DATACMNS-836 branch from 3f01027 to 186e9e9 Compare October 10, 2016 11:10

mp911de mentioned this pull request Oct 21, 2016

DATACASS-335 - Add support for reactive data access. spring-projects/spring-data-cassandra#86

Closed

mp911de force-pushed the issue/DATACMNS-836 branch 2 times, most recently from 9f89c8c to ecb0fe6 Compare October 27, 2016 08:57

mp911de commented Oct 31, 2016

View reviewed changes

odrotbohm added 3 commits November 4, 2016 17:09

DATACMNS-864 - Prepare 2.0 development.

ed1d2c1

Upgraded to Spring Data Build parent 2.0 snapshots. Removed obsolete distribution key property. Removed obsolete template.mf.

DATACMNS-864 - Fix Java 8 compiler ambiguities.

1933488

Added explicit generics invocations in places that caused an ambiguous invocation on Java 8.

DATACMNS-919 - Removed deprecated DomainClassPropertyEditor and -Regi…

2b70e5a

…strar.

odrotbohm force-pushed the 2.0.x branch from e240852 to 2b70e5a Compare November 4, 2016 16:11

mp911de added 2 commits November 4, 2016 17:12

DATACMNS-836 - Investigate API to support reactive paradigms.

e372ee0

Prepare issue branch.

DATACMNS-836 - Add reactor-core dependency.

f3ba640

odrotbohm force-pushed the issue/DATACMNS-836 branch from ecb0fe6 to 33750a6 Compare November 4, 2016 16:14

mp911de and others added 5 commits November 8, 2016 10:50

DATACMNS-836 - Upgraded to Reactor Core 2.5 M4.

86cee7d

DATACMNS-836 - Provide wrapper conversion, ReactiveWrappers and RxJav…

1430302

…a 2 type conversion.

mp911de force-pushed the issue/DATACMNS-836 branch from 1c006fb to 8155b28 Compare November 8, 2016 09:51

mp911de and others added 3 commits November 10, 2016 17:07

DATACMNS-836 - Apply deferred reactive type conversion as RxJava's Pu…

6106e6e

…blisherAdapter keep state between multiple subscribers.

DATACMNS-836 - Enhance JavaDoc.

fb59dde

DATACMNS-836 - Favor usage of Function over Converter.

c8ea914

odrotbohm reviewed Nov 13, 2016

View reviewed changes

odrotbohm force-pushed the issue/DATACMNS-836 branch from abac726 to 7ea8c9d Compare November 13, 2016 17:58

odrotbohm added 2 commits November 14, 2016 12:08

DATACMNS-836 - Introduced base class for reactive repository factories.

7607544

Introduced ReactiveRepositoryFactorySupport so that validation for the presence of all required converters (e.g. RxJava 1) does not have to be repeated in individual stores.

mp911de force-pushed the issue/DATACMNS-836 branch from 5e35e3a to 2d17ae4 Compare November 14, 2016 13:37

mp911de force-pushed the issue/DATACMNS-836 branch from 2d17ae4 to c8ea943 Compare November 14, 2016 13:47

odrotbohm force-pushed the 2.0.x branch from 2b70e5a to 3f3ab49 Compare November 14, 2016 14:40

odrotbohm closed this Nov 14, 2016

odrotbohm deleted the issue/DATACMNS-836 branch November 14, 2016 18:53

Aloren pushed a commit to Aloren/spring-data-commons that referenced this pull request Jun 20, 2019

Extract target from @ConfigurationProperties proxy

8347c57

Fixes spring-projectsgh-175 (more of a workaround really and spring-projectsgh-177 is still open to track further changes).

Aloren pushed a commit to Aloren/spring-data-commons that referenced this pull request Jun 20, 2019

Use the new ConfigurationPropertiesBinder API from Spring Boot

8357724

Fixes spring-projectsgh-177

spring-projects-issues mentioned this pull request Dec 30, 2020

Add components to support reactive repositories [DATACMNS-836] #1298

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

DATACMNS-836 - Add components to support reactive repositories. #177

DATACMNS-836 - Add components to support reactive repositories. #177

Uh oh!

mp911de commented Sep 21, 2016 •

edited

Loading

Uh oh!

mp911de commented Oct 28, 2016

Uh oh!

mp911de Oct 31, 2016

Uh oh!

mp911de Oct 31, 2016

Uh oh!

odrotbohm left a comment

Uh oh!

odrotbohm Nov 13, 2016

Uh oh!

mp911de Nov 14, 2016

Uh oh!

odrotbohm Nov 13, 2016

Uh oh!

odrotbohm Nov 13, 2016

Uh oh!

odrotbohm Nov 13, 2016

Uh oh!

mp911de Nov 14, 2016

Uh oh!

odrotbohm commented Nov 13, 2016

Uh oh!

Uh oh!

DATACMNS-836 - Add components to support reactive repositories. #177

DATACMNS-836 - Add components to support reactive repositories. #177

Uh oh!

Conversation

mp911de commented Sep 21, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mp911de commented Oct 28, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odrotbohm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

odrotbohm commented Nov 13, 2016

Uh oh!

Uh oh!

mp911de commented Sep 21, 2016 •

edited

Loading