Add support for Coroutines repositories [DATACMNS-1508]

[spring-projects-issues]

Sébastien Deleuze opened DATACMNS-1508 and commented

As a complement of Coroutines extensions, for the sake of parity with the Reactor and RxJava support and because Coroutines allow to leverage Reactive infrastructure in a more imperative way, and for consistency with Spring WebFlux which provides both functional and annotation variants, I think it would be great if Spring Data could support Coroutines repositories.

With he recently released Flow type, it is now possible to provide such API that I have drafted:

@NoRepositoryBean
public interface CoCrudRepository<T, ID> : Repository<T, ID> {

	suspend fun save(entity: T): T

	fun saveAll(entities: Iterable<T>): Flow<T>

	fun saveAll(entityStream: Flow<T>): Flow<T>

	suspend fun findById(id: ID): T?

	suspend fun findById(id: Flow<ID>): T?

	suspend fun existsById(id: ID): Boolean

	suspend fun existsById(id: Flow<ID>): Boolean

	fun findAll(): Flow<T>

	fun findAllById(ids: Iterable<ID> ): Flow<T>

	fun findAllById(idStream: Flow<ID>): Flow<T>

	suspend fun count(): Long

	suspend fun deleteById(id: ID)

	suspend fun deleteById(id: Flow<ID>)

	suspend fun delete(entity: T)

	suspend fun deleteAll(entities: Iterable<out T>)

	suspend fun deleteAll(entityStream: Flow<out T>)

	suspend fun deleteAll()
}

Notice that Spring Framework 5.2 ReactiveAdapterRegistry supports Flow <-> Publisher adaptation, that MethodParameter is now Coroutines compliant, and that Spring Framework is able to adapt suspending functions to Mono even if this is not exposed yet (we could expose it for Spring Data needs).

Based on what we did on Framework side, it seems possible to implement Coroutines repositories like RxJava ones and consider it as an alternative API that we adapt to leverage our Reactive infrastructure.

Such API would be very popular I think.
 

---

Issue Links:

• DATACMNS-1608 Support Kotlin's Flow
  ("is duplicated by")
• DATACMNS-949 Drop own Converters and use ReactiveAdapterRegistry directly where possible

Referenced from: pull request #415

4 votes, 5 watchers

[spring-projects-issues]

Mark Paluch commented

We discussed in our team how to proceed with this item and came to the conclusion that we want to move Coroutine repositories to our next release train. The main reason is that we need to consider how to package repositories as a Coroutine repository is no longer a pure extension. It's a class that will be visible to Java users.

This is one of the many reasons why we consider splitting up Spring Data Commons into multiple submodules (e.g. web part, repository part for Java and repository for Kotlin).

Given that we have only 6 weeks until we hit RC1 this is not feasible to achieve that goal within the remaining timeframe

[spring-projects-issues]

Sébastien Deleuze commented

Ok thanks for your feedback. Please ping me when you will start working on that, I would like to discuss with you how we could expose Spring Framework CoroutinesUtils class for external usage like this Spring Data use case