On Fri, Jun 13, 2014 at 5:25 PM, Richard Rodseth <[email protected]> wrote:
> Hi Patrik > > I'll try to clarify, though I think this minor code reuse point is > tangential to my main question about the appropriateness of the ask pattern > between service and blocking DAO. > > I suppose I should look at the ask pattern source code, but presumably it > is counting on the recipient to reply to sender. So UserDAOActor must be > written > > case FetchUser(id: Int) => > sender ! BlockingUserDAO.fetchUserById(id) > > > Now, I understand that this same actor could also be used with tell() > passing in a sender ref. But that version of tell feels a little like > breaking an abstraction. Referring to something called sender which > actually isn't the sender. If I were designing an actor to send a result > somewhere, I might be more inclined to be specific about the destination > and inject it into the actor or include it in the message. But then that > actor couldn't be used with ask(). > > I am content with writing UserDAO as above if you agree that the ask() > pattern is fine in this case. I was just musing about how to share code > between the askable actor and the tellable actor. > > You could use two different messages, one that includes the `sendResultTo: ActorRef`, and one that doesn't (and then use sender()). /Patrik > > > > > > On Thu, Jun 12, 2014 at 11:16 PM, Patrik Nordwall < > [email protected]> wrote: > >> 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. >> > > -- > >>>>>>>>>> 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.
