Correct way to execute multiple reactive operations
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I get from a reactive repository a Mono<FooBar>
based on it's value I have to create two other objects save them using reactive repositories, modify FooBar
object and save it as well.
As I'm new to reactive programming I landed with the following solution, which is working, but I'm not sure if I'm using correctly the reactive API:
@Test
void createAndSave() {
Mono<FooBar> fooBarMono = findFooBar() // returns Mono<FooBar>
.map(fooBar -> {
createAndSaveLoremBar(fooBar).subscribe(); // returns Mono<LoremBar>
createAndSaveDoloremBar(fooBar).subscribe(); // returns Mono<DoloremBar>
fooBar.setActive(true);
return saveFooBar(fooBar); // returns Mono<FooBar>
}).flatMap(Function.identity());
StepVerifier.create(fooBarMono)
.expectNextMatches(Objects::nonNull)
.expectComplete()
.verify();
}
from console log:
saved lorem bar
saved dolorem bar
saved foo bar
spring-data-mongodb spring-webflow project-reactor
add a comment |
I get from a reactive repository a Mono<FooBar>
based on it's value I have to create two other objects save them using reactive repositories, modify FooBar
object and save it as well.
As I'm new to reactive programming I landed with the following solution, which is working, but I'm not sure if I'm using correctly the reactive API:
@Test
void createAndSave() {
Mono<FooBar> fooBarMono = findFooBar() // returns Mono<FooBar>
.map(fooBar -> {
createAndSaveLoremBar(fooBar).subscribe(); // returns Mono<LoremBar>
createAndSaveDoloremBar(fooBar).subscribe(); // returns Mono<DoloremBar>
fooBar.setActive(true);
return saveFooBar(fooBar); // returns Mono<FooBar>
}).flatMap(Function.identity());
StepVerifier.create(fooBarMono)
.expectNextMatches(Objects::nonNull)
.expectComplete()
.verify();
}
from console log:
saved lorem bar
saved dolorem bar
saved foo bar
spring-data-mongodb spring-webflow project-reactor
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59
add a comment |
I get from a reactive repository a Mono<FooBar>
based on it's value I have to create two other objects save them using reactive repositories, modify FooBar
object and save it as well.
As I'm new to reactive programming I landed with the following solution, which is working, but I'm not sure if I'm using correctly the reactive API:
@Test
void createAndSave() {
Mono<FooBar> fooBarMono = findFooBar() // returns Mono<FooBar>
.map(fooBar -> {
createAndSaveLoremBar(fooBar).subscribe(); // returns Mono<LoremBar>
createAndSaveDoloremBar(fooBar).subscribe(); // returns Mono<DoloremBar>
fooBar.setActive(true);
return saveFooBar(fooBar); // returns Mono<FooBar>
}).flatMap(Function.identity());
StepVerifier.create(fooBarMono)
.expectNextMatches(Objects::nonNull)
.expectComplete()
.verify();
}
from console log:
saved lorem bar
saved dolorem bar
saved foo bar
spring-data-mongodb spring-webflow project-reactor
I get from a reactive repository a Mono<FooBar>
based on it's value I have to create two other objects save them using reactive repositories, modify FooBar
object and save it as well.
As I'm new to reactive programming I landed with the following solution, which is working, but I'm not sure if I'm using correctly the reactive API:
@Test
void createAndSave() {
Mono<FooBar> fooBarMono = findFooBar() // returns Mono<FooBar>
.map(fooBar -> {
createAndSaveLoremBar(fooBar).subscribe(); // returns Mono<LoremBar>
createAndSaveDoloremBar(fooBar).subscribe(); // returns Mono<DoloremBar>
fooBar.setActive(true);
return saveFooBar(fooBar); // returns Mono<FooBar>
}).flatMap(Function.identity());
StepVerifier.create(fooBarMono)
.expectNextMatches(Objects::nonNull)
.expectComplete()
.verify();
}
from console log:
saved lorem bar
saved dolorem bar
saved foo bar
spring-data-mongodb spring-webflow project-reactor
spring-data-mongodb spring-webflow project-reactor
asked Nov 16 '18 at 20:44
A5300A5300
828
828
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59
add a comment |
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59
add a comment |
2 Answers
2
active
oldest
votes
At first, mutating objects in the asynchronous (reactive) world is not a good idea.
Anyway, in your solution possible errors on lorem and dolorem saving are ignored. You can improve it like so:
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar)) // asynchronously saving lorem and dolorem
.then(Mono.fromCallable(() -> { // if there wasn't errors, mutate and save fooBar
fooBar.setActive(true);
return fooBar;
}).flatMap(fooBar1 -> saveFooBar(fooBar1))));
If you could create copy of your fooBar
with true active
flag, the code could be simpler. For example with lombok.
@Builder(toBuilder = true)
public class FooBar {
...
}
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar))
.then(saveFooBar(fooBar.toBuilder().active(true).build())));
And if you are not interested in the result of your saveFooBar(...)
but only in the completion signal, you could make all three saves asynchronously:
Flux<Object> flux = findFooBar()
.flatMapMany(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar),
saveFooBar(fooBar.toBuilder().active(true).build())));
Actually, in the last approach you could collect all three results and you should prefer this approach, but I don't have enough information about your classes and requirements for creating full example.
add a comment |
I think the bellow solution is a little bit more readable. Anyway Alexander is correct you should never ever modify the input. You see we are borrowing a lot of concept form functional programming. For example you call Function.identity()
this is called
identity functor
. Both Flux
and Mono
are monads. And there is a concept that is secret for these guys called Referential transparency
that imperative update break.
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar))
.map(tuple -> tuple.getT1())
.zipWhen((fooBar) -> createAndSaveDoloremBar(fooBar))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
Or more concise:
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar)
.then(createAndSaveDoloremBar(fooBar)))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53345130%2fcorrect-way-to-execute-multiple-reactive-operations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
At first, mutating objects in the asynchronous (reactive) world is not a good idea.
Anyway, in your solution possible errors on lorem and dolorem saving are ignored. You can improve it like so:
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar)) // asynchronously saving lorem and dolorem
.then(Mono.fromCallable(() -> { // if there wasn't errors, mutate and save fooBar
fooBar.setActive(true);
return fooBar;
}).flatMap(fooBar1 -> saveFooBar(fooBar1))));
If you could create copy of your fooBar
with true active
flag, the code could be simpler. For example with lombok.
@Builder(toBuilder = true)
public class FooBar {
...
}
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar))
.then(saveFooBar(fooBar.toBuilder().active(true).build())));
And if you are not interested in the result of your saveFooBar(...)
but only in the completion signal, you could make all three saves asynchronously:
Flux<Object> flux = findFooBar()
.flatMapMany(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar),
saveFooBar(fooBar.toBuilder().active(true).build())));
Actually, in the last approach you could collect all three results and you should prefer this approach, but I don't have enough information about your classes and requirements for creating full example.
add a comment |
At first, mutating objects in the asynchronous (reactive) world is not a good idea.
Anyway, in your solution possible errors on lorem and dolorem saving are ignored. You can improve it like so:
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar)) // asynchronously saving lorem and dolorem
.then(Mono.fromCallable(() -> { // if there wasn't errors, mutate and save fooBar
fooBar.setActive(true);
return fooBar;
}).flatMap(fooBar1 -> saveFooBar(fooBar1))));
If you could create copy of your fooBar
with true active
flag, the code could be simpler. For example with lombok.
@Builder(toBuilder = true)
public class FooBar {
...
}
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar))
.then(saveFooBar(fooBar.toBuilder().active(true).build())));
And if you are not interested in the result of your saveFooBar(...)
but only in the completion signal, you could make all three saves asynchronously:
Flux<Object> flux = findFooBar()
.flatMapMany(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar),
saveFooBar(fooBar.toBuilder().active(true).build())));
Actually, in the last approach you could collect all three results and you should prefer this approach, but I don't have enough information about your classes and requirements for creating full example.
add a comment |
At first, mutating objects in the asynchronous (reactive) world is not a good idea.
Anyway, in your solution possible errors on lorem and dolorem saving are ignored. You can improve it like so:
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar)) // asynchronously saving lorem and dolorem
.then(Mono.fromCallable(() -> { // if there wasn't errors, mutate and save fooBar
fooBar.setActive(true);
return fooBar;
}).flatMap(fooBar1 -> saveFooBar(fooBar1))));
If you could create copy of your fooBar
with true active
flag, the code could be simpler. For example with lombok.
@Builder(toBuilder = true)
public class FooBar {
...
}
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar))
.then(saveFooBar(fooBar.toBuilder().active(true).build())));
And if you are not interested in the result of your saveFooBar(...)
but only in the completion signal, you could make all three saves asynchronously:
Flux<Object> flux = findFooBar()
.flatMapMany(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar),
saveFooBar(fooBar.toBuilder().active(true).build())));
Actually, in the last approach you could collect all three results and you should prefer this approach, but I don't have enough information about your classes and requirements for creating full example.
At first, mutating objects in the asynchronous (reactive) world is not a good idea.
Anyway, in your solution possible errors on lorem and dolorem saving are ignored. You can improve it like so:
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar)) // asynchronously saving lorem and dolorem
.then(Mono.fromCallable(() -> { // if there wasn't errors, mutate and save fooBar
fooBar.setActive(true);
return fooBar;
}).flatMap(fooBar1 -> saveFooBar(fooBar1))));
If you could create copy of your fooBar
with true active
flag, the code could be simpler. For example with lombok.
@Builder(toBuilder = true)
public class FooBar {
...
}
Mono<FooBar> fooBarMono = findFooBar()
.flatMap(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar))
.then(saveFooBar(fooBar.toBuilder().active(true).build())));
And if you are not interested in the result of your saveFooBar(...)
but only in the completion signal, you could make all three saves asynchronously:
Flux<Object> flux = findFooBar()
.flatMapMany(fooBar -> Flux.merge(
createAndSaveLoremBar(fooBar),
createAndSaveDoloremBar(fooBar),
saveFooBar(fooBar.toBuilder().active(true).build())));
Actually, in the last approach you could collect all three results and you should prefer this approach, but I don't have enough information about your classes and requirements for creating full example.
answered Nov 17 '18 at 16:32
Alexander PankinAlexander Pankin
1,06129
1,06129
add a comment |
add a comment |
I think the bellow solution is a little bit more readable. Anyway Alexander is correct you should never ever modify the input. You see we are borrowing a lot of concept form functional programming. For example you call Function.identity()
this is called
identity functor
. Both Flux
and Mono
are monads. And there is a concept that is secret for these guys called Referential transparency
that imperative update break.
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar))
.map(tuple -> tuple.getT1())
.zipWhen((fooBar) -> createAndSaveDoloremBar(fooBar))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
Or more concise:
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar)
.then(createAndSaveDoloremBar(fooBar)))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
add a comment |
I think the bellow solution is a little bit more readable. Anyway Alexander is correct you should never ever modify the input. You see we are borrowing a lot of concept form functional programming. For example you call Function.identity()
this is called
identity functor
. Both Flux
and Mono
are monads. And there is a concept that is secret for these guys called Referential transparency
that imperative update break.
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar))
.map(tuple -> tuple.getT1())
.zipWhen((fooBar) -> createAndSaveDoloremBar(fooBar))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
Or more concise:
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar)
.then(createAndSaveDoloremBar(fooBar)))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
add a comment |
I think the bellow solution is a little bit more readable. Anyway Alexander is correct you should never ever modify the input. You see we are borrowing a lot of concept form functional programming. For example you call Function.identity()
this is called
identity functor
. Both Flux
and Mono
are monads. And there is a concept that is secret for these guys called Referential transparency
that imperative update break.
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar))
.map(tuple -> tuple.getT1())
.zipWhen((fooBar) -> createAndSaveDoloremBar(fooBar))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
Or more concise:
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar)
.then(createAndSaveDoloremBar(fooBar)))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
I think the bellow solution is a little bit more readable. Anyway Alexander is correct you should never ever modify the input. You see we are borrowing a lot of concept form functional programming. For example you call Function.identity()
this is called
identity functor
. Both Flux
and Mono
are monads. And there is a concept that is secret for these guys called Referential transparency
that imperative update break.
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar))
.map(tuple -> tuple.getT1())
.zipWhen((fooBar) -> createAndSaveDoloremBar(fooBar))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
Or more concise:
final Mono<FooBar> fooBarMono1 = findFooBar()
.zipWhen((fooBar) -> createAndSaveLoremBar(fooBar)
.then(createAndSaveDoloremBar(fooBar)))
.map(tuple -> tuple.getT1())
.map(fooBar -> new FooBar(true))
.flatMap(fooBar -> saveFooBar(fooBar));
answered Nov 25 '18 at 22:24
piotr szybickipiotr szybicki
7011511
7011511
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53345130%2fcorrect-way-to-execute-multiple-reactive-operations%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Is it required to save lorem bar and dolorem bar before activating fooBar? And what about errors on lorem and dolorem saving? Should we ignore or propagate errors?
– Alexander Pankin
Nov 16 '18 at 23:09
@AlexanderPankin the order of saving doesn't matter; errors should be propagated if possible
– A5300
Nov 17 '18 at 11:59