Hi Richard,
On Wed, Jun 11, 2014 at 9:00 PM, Richard Rodseth <[email protected]> wrote: > I realize this is well-trodden ground, but it's still a bit confusing for > newcomers. > > Can we agree that the ask pattern is legitimate at the boundary between a > service and repository/DAO? > > It seems to me that it is reasonable to want to abstract away the > persistence layer in a way that doesn't *assume* actors. ie: > > trait UserDAOBlocking { > def getUser(id:UserId):Try[User] > } > > and/or > > trait UserDAOAsync { > def getUser(id:UserId):Future[User] > } > > Now perhaps an implementation of UserDAOAsync would use an actor and > perhaps another would use Future { ...} > > Perhaps the actor (UserDAOActor) would inject an implementation of > UserDAOBlocking. > > Now suppose your client code *is* actor-aware. Then you might wish to use > a UserDAOActor directly. > > In the following sample: > > > https://github.com/lucperkins/spray-akka-slick-postgres/blob/master/src/main/scala/app/server/TaskService.scala > > he uses an actor (accessed directly in the Spray route) as follows > > > val postgresWorker = actorRefFactory.actorOf(Props[PostgresActor], > "postgres-worker") > > > def postgresCall(message: Any) = > (postgresWorker ? message).mapTo[String].map(result => result) > > > val taskServiceRoutes = { > > pathPrefix("tasks") { > path("") { > get { ctx => > ctx.complete(postgresCall(FetchAll)) > } ~ > > Note the ask pattern. Still OK? > > The PostgresWorker actor in this sample sends its results back to sender > > case FetchTask(id: Int) => > sender ! TaskDAO.fetchTaskById(id) > > > https://github.com/lucperkins/spray-akka-slick-postgres/blob/master/src/main/scala/app/actors/PostgresActor.scala > > I'm wondering if there's a way to have two versions of this actor so that > it can be used with both ask() and in a chaining fashion? It looks as > though ask() does not have the equivalent of the version of tell that takes > an explicit sender ref. Perhaps mix in a behaviour trait with a function > that creates a Receive partial function, with the resultHandler as a > parameter? > I'm not sure I understand the question. The destination actor can be the same, it only replies to the sender(). The Future, returned from ask, can be piped to another actor, which would be rather similar as tell with explicit sender ref. /Patrik > > def queryMessages(resultHandler:ActorRef):Receive = { > ... > ] > > Hmm. > > Thanks. > > > -- > >>>>>>>>>> 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 http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > -- Patrik Nordwall Typesafe <http://typesafe.com/> - Reactive apps on the JVM Twitter: @patriknw <http://www.scaladays.org/> -- >>>>>>>>>> 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 http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
