Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Coroutines repositories [DATACMNS-1508] #1941

Closed
spring-projects-issues opened this issue Apr 5, 2019 · 2 comments
Closed

Add support for Coroutines repositories [DATACMNS-1508] #1941

spring-projects-issues opened this issue Apr 5, 2019 · 2 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Apr 5, 2019

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 23, 2019

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
Copy link
Author

@spring-projects-issues spring-projects-issues commented Apr 23, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants