Closed nino-stokbro-ag closed 1 year ago
Why do you consider .then(Mono.just("something"))
a trick? repo.delete(…).then(otherRepo.save(…))
is fully aligned with the intended usage. You mentioned .map(…)
a couple of times, hinting at a code smell that you're trying to follow a pattern for your project that isn't meant to be that way.
Happy to continue the discussion over a bit of your code that you consider problematic for yourself.
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.
Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.
We have scenarios where we want to continue doing further activities on the reactive flow after performing a delete operation on the repo. This is easy for derived modifying queries as we can just declare them to return Mono\<Integer> or Mono\<Boolean> and then continue the flow with a map function.
However the predefined delete and deleteById methods return Mono\<Void> which means it doesn't emit a next signal, only a completion signal. This makes the continuing of the flow cumbersome as we have to do tricks like
repo.delete(product).then(Mono.just("something"))
in order to be able to continue the flow with a map function.Since it is a very common occurrence for us it is annoying to have to do this all the time, but even more importantly if the developer forgets to do the
.then(Mono.just("something"))
and just continues directly on the delete with a map, then the rest of the flow is just silently ignored and hopefully they will catch the mistake in a test.Do you have a better solution to how to continue the reactive flow after a delete operation return Mono\<Void> or would it be possible to change the repository interface to declare the delete and deleteById operation to return Mono\<Boolean> or Mono\<Integer> instead?