StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
20417884
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
2
CommunityOwnedDate
CreationDate
2013-12-06T06:54:00.817
FavoriteCount
0
LastActivityDate
2017-12-07T14:43:44.453
LastEditDate
2017-12-07T14:43:44.453
LastEditorUserId
2906175
OwnerUserId
1528401
ParentId
20414500
PostTypeId
2
Score
36
ViewCount
0
LastEditorDisplayName
text
Body
If you don't mind a very localised <code>var</code>, you can serialise the asynchronous processing (each <code>f(item)</code>) as follows (<code>flatMap</code> does the serialization): <pre><code>val fSerialized = { var fAccum = Future{()} for(item <- it) { println(s"Processing ${item}") fAccum = fAccum flatMap { _ => f(item) } } fAccum } fSerialized.onComplete{case resTry => println("All Done.")} </code></pre> In general, avoid <code>Await</code> operations - they block (kind of defeats the point of async, consumes resources and for sloppy designs, can deadlock) <hr> Cool Trick 1: You can chain together <code>Futures</code> via that usual suspect, <code>flatmap</code> - it serializes asynchronous operations. Is there anything it can't do? ;-) <pre><code>def f1 = Future { // some background running logic here...} def f2 = Future { // other background running logic here...} val fSerialized: Future[Unit] = f1 flatMap(res1 => f2) fSerialized.onComplete{case resTry => println("Both Done: Success=" + resTry.isSuccess)} </code></pre> None of the above blocks - the main thread runs straight through in a few dozen nanoseconds. Futures are used in all cases to execute parallel threads and keep track of asynchronous state/results and to chain logic. <code>fSerialized</code> represents a composite of two different asynchronous operations chained together. As soon as the val is evaluated, it immediately starts <code>f1</code> (running asynchonously). <code>f1</code> runs like any <code>Future</code> - when it eventually finishes, it calls it's <code>onComplete</code> callback block. Here's the cool bit - <code>flatMap</code> installs it's argument as the <code>f1</code> onComplete callback block - so <code>f2</code> is initiated as soon as <code>f1</code> completes, with no blocking, polling or wasteful resource usage. When <code>f2</code> is complete, then <code>fSerialized</code> is complete - so it runs the <code>fSerialized.onComplete</code> callback block - printing "Both Done". Not only that, but you can chain flatmaps as much as you like with neat non-spaghetti code <pre><code> f1 flatmap(res1 => f2) flatMap(res2 => f3) flatMap(res3 => f4) ... </code></pre> If you were to do that via Future.onComplete, you would have to embed the successive operations as nested onComplete layers: <pre><code>f1.onComplete{case res1Try => f2 f2.onComplete{case res2Try => f3 f3.onComplete{case res3Try => f4 f4.onComplete{ ... } } } } </code></pre> Not as nice. Test to prove: <pre><code>import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global import scala.concurrent.blocking import scala.concurrent.duration._ def f(item: Int): Future[Unit] = Future{ print("Waiting " + item + " seconds ...") Console.flush blocking{Thread.sleep((item seconds).toMillis)} println("Done") } val fSerial = f(4) flatMap(res1 => f(16)) flatMap(res2 => f(2)) flatMap(res3 => f(8)) fSerial.onComplete{case resTry => println("!!!! That's a wrap !!!! Success=" + resTry.isSuccess)} </code></pre> Cool Trick 2: for-comprehensions like this: <pre><code>for {a <- aExpr; b <- bExpr; c <- cExpr; d <- dExpr} yield eExpr </code></pre> are nothing but syntactic-sugar for this: <pre><code>aExpr.flatMap{a => bExpr.flatMap{b => cExpr.flatMap{c => dExpr.map{d => eExpr} } } } </code></pre> that's a chain of flatMaps, followed by a final map. That means that <pre><code>f1 flatmap(res1 => f2) flatMap(res2 => f3) flatMap(res3 => f4) map(res4 => "Did It!") </code></pre> is identical to <pre><code>for {res1 <- f1; res2 <- f2; res3 <- f3; res4 <- f4} yield "Did It!" </code></pre> Test to Prove (following on from previous test): <pre><code>val fSerial = for {res1 <- f(4); res2 <- f(16); res3 <- f(2); res4 <- f(8)} yield "Did It!" fSerial.onComplete{case resTry => println("!!!! That's a wrap !!!! Success=" + resTry.isSuccess)} </code></pre> Not-So-Cool Trick 3: Unfortunately you can't mix iterators & futures in the same for-comprehension. Compile error: <pre><code>val fSerial = {for {nextItem <- itemIterable; nextRes <- f(nextItem)} yield "Did It"}.last </code></pre> And nesting fors creates a challenge. The following doesn't serialize, but runs async blocks in parallel (nested comprehensions don't chain subsequent Futures with flatMap/Map, but instead chains as Iterable.flatMap{item => f(item)} - not the same!) <pre><code>val fSerial = {for {nextItem <- itemIterable} yield for {nextRes <- f(nextItem)} yield "Did It"}.last </code></pre> Also using foldLeft/foldRight plus flatMap doesn't work as you'd expect - seems a bug/limitation; all async blocks are processed in parallel (so <code>Iterator.foldLeft/Right</code> is not sociable with <code>Future.flatMap</code>): <pre><code>import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global import scala.concurrent.blocking import scala.concurrent.duration._ def f(item: Int): Future[Unit] = Future{ print("Waiting " + item + " seconds ...") Console.flush blocking{Thread.sleep((item seconds).toMillis)} println("Done") } val itemIterable: Iterable[Int] = List[Int](4, 16, 2, 8) val empty = Future[Unit]{()} def serialize(f1: Future[Unit], f2: Future[Unit]) = f1 flatMap(res1 => f2) //val fSerialized = itemIterable.iterator.foldLeft(empty){(fAccum, item) => serialize(fAccum, f(item))} val fSerialized = itemIterable.iterator.foldRight(empty){(item, fAccum) => serialize(fAccum, f(item))} fSerialized.onComplete{case resTry => println("!!!! That's a wrap !!!! Success=" + resTry.isSuccess)} </code></pre> But this works (var involved): <pre><code>import scala.concurrent.Future import scala.concurrent.ExecutionContext.Implicits.global import scala.concurrent.blocking import scala.concurrent.duration._ def f(item: Int): Future[Unit] = Future{ print("Waiting " + item + " seconds ...") Console.flush blocking{Thread.sleep((item seconds).toMillis)} println("Done") } val itemIterable: Iterable[Int] = List[Int](4, 16, 2, 8) var fSerial = Future{()} for {nextItem <- itemIterable} fSerial = fSerial.flatMap(accumRes => f(nextItem)) </code></pre>
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POhow to do sequential execution of Futures in scala
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USpeedeeX21
UserOwnerUserId
1. USGlen Best
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POhow to do sequential execution of Futures in scala
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. COUsing foldLeft/foldRight plus flatMap *does* work as expected. By exemple `items.foldLeft(Future()){(x,y) => x.flatMap{_=>f(y)}}` does exactly why you'd expect (executing `f(y)` serially for every `y` in `items`. The reason why it does not work in your case is that you are using a helper method `serialize` where the right hand future (`f2`) is passed by value, thereby forcing its early evaluation. Passing `f2` by name should fix it: `def serialize(f1: Future[Unit], f2: => Future[Unit])`. While you're at it, you might as well pass `f1` by name too.
 singulars
 PostPostId
 PO
 UserUserId
 USRégis Jean-Gilles
2. COThanks guys, the folding behavior works great!
 singulars
 PostPostId
 PO
 UserUserId
 USuser776635

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.