wow, this is not definitely well described in the current documentation. I
went through a similar chain of mistakes and misconceptions regarding the
semantic of the new groupBy/merge primitives. Thanks Debassigh for bringing
this here. Regards, Juanjo.
El miércoles, 27 de abril de 2016,
Thanks for the clarification. A good point to keep in mind.
regards.
On Wed, Apr 27, 2016 at 11:22 AM, Roland Kuhn wrote:
> Hi Debasish,
>
> The current fusing algorithm is called «aggressive» for a reason: it will
> fuse everything it can. To run the subflows in parallel
Hi Debasish,
The current fusing algorithm is called «aggressive» for a reason: it will fuse
everything it can. To run the subflows in parallel you will have to add a
.async after the fold. But that will only be beneficial if the monoid’s |+| is
rather expensive.
Regards, Roland
Sent from my
Thanks Roland a lot for the clarification .. I can do this ..
val netTxn: RunnableGraph[Future[akka.Done]] =
transactions.map(validate)
.groupBy(MaxGroupCount, _.accountNo)
.fold(TransactionMonoid.zero)(_ |+| _)
.mergeSubstreams
Only difference
> 26 apr 2016 kl. 20:14 skrev Debasish Ghosh :
>
> Just for the sake of completeness, this works ..
>
> transactions.map(validate)
> .groupBy(MaxGroupCount, _.accountNo)
> .fold(Map.empty[String, Transaction])((l, r) => l |+|
> Map(r.accountNo
The fold will be sequential
On Tue, Apr 26, 2016 at 9:20 PM, Debasish Ghosh
wrote:
> Actually I realized just now that I don't need the groupBy and
> mergeStreams for this .. Just the following will also do ..
>
> transactions.map(validate)
>
Actually I realized just now that I don't need the groupBy and mergeStreams
for this .. Just the following will also do ..
transactions.map(validate)
.fold(Map.empty[String, Transaction])((l, r) => l |+|
Map(r.accountNo -> r))
And the example in the Streams Cookbook for counting
Just for the sake of completeness, this works ..
transactions.map(validate)
.groupBy(MaxGroupCount, _.accountNo)
.fold(Map.empty[String, Transaction])((l, r) => l |+|
Map(r.accountNo -> r))
.mergeSubstreams
Since I cannot access the sub-streams I need to
If you can devise a safe version of groupBy that lets us preserve that nice
quality then I am more than all ears.
--
Cheers,
√
On Apr 26, 2016 8:02 PM, "Debasish Ghosh" wrote:
> Thanks Viktor .. my main issue is that we lose the natural semantics of
> groupBy as we
Thanks Viktor .. my main issue is that we lose the natural semantics of
groupBy as we learnt from SQL. We cannot access the substreams as separate
abstractions that groupBy creates.
On Tue, Apr 26, 2016 at 11:28 PM, Viktor Klang
wrote:
> Debasish,
>
> The problem with
Debasish,
The problem with groupBy was that it was too easy to create leaks and
silently broken solutions with it, but I sympathize with your situation, I
also felt the original as being more ergonomic. I think there is room for
improvement in the current solution.
--
Cheers,
√
On Apr 26, 2016
Roland -
The problem is I cannot access the substreams separately within the fold.
In the earlier solution the fold was on individual substreams (not on the
whole stream). Here the fold gets *all* the elements from all substreams
and I lose the ability to process substreams separately. Hence I
Instead of using a fold sink which materializes to a Future you’ll need to use
a fold combinator which produces the result as its only value after the
substream has completed, i.e. you keep the computation results within the
streaming domain a bit longer instead of going to the Future domain
Hi -
I am trying to migrate some akka-streams code from an earlier version
(akka-stream-experimental 1.0.RC4) .. please have a look at the following ..
/**
* Create multiple streams out of a single stream. The stream
"transactions" is being
* demultiplexed into many streams split by account
14 matches
Mail list logo