On Friday, November 4, 2016 at 8:43:43 AM UTC-4, √ wrote: > > Why would it need its own materializer? >
I have a stream of IDs, coming from the database. There is the flow, that maps the ID into the profile ( fetch the details from some external storage ). So far it is simple enough - val profileFetcher = Flow.fromFunction[ID, Profile, NotUsed](id ⇒ ....) Now I have to take the *profile* and run another flow, that will - query 1 .. N different resources (depending on the content of Profile) - transform the content of the resources and save them into a separate file (*sink*) - aggregate results of that processing (for now - calculate the number of records fetched from external resources) and update the *profile* object - stream down the *profile* object into another file (*sink)*. So far I can see that the function, that goes downstream val profileSaver = Flow.fromFunction[Profile, ByteString, NotUsed] = (profile ⇒ ....) must take the profile, create it's own flow, *wait until that flow completes* and then update the profile object before converting it into a *ByteString*. And that's why I need to materialize the inner flow. Makes sense? -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
