On 10.03.14 11:36, Mike wrote:
Thanks Martin and Patrik. That makes sense but I have a number of
views that aggregate data in different ways. If I need to have a one
to one correspondence between Views and Processors, it seems like I
would need to tightly couple the creation of those Views to the
Processors (or their supervisors). This would tightly link these two
parts of the application when otherwise the processors don't need to
have any knowledge of the views. Am I going about this the wrong way?
Not sure I get your point. Processors are comepletely unaware of the
existence of corresponding views. Also, there's no coupling of the
lifetime of view actors and their corresponding processor actor.
Does that answer your question?
On Friday, March 7, 2014 1:39:52 AM UTC-6, Patrik Nordwall wrote:
On Thu, Mar 6, 2014 at 7:01 PM, Mike <[email protected]
<javascript:>> wrote:
Using an in memory projection seems to work great. The only
limitation I've run into (which may be just a limitation in my
understanding ...) is that a view can only monitor the event
stream for a single processor. I require a view to aggregate
state across a large number of processors
Can't you achieve this by having many one-to-one Views that
forwards the events to one aggregator actor?
so I've resorted to using a pub/sub mechanism. But is there a
mechanism or design to support a view monitoring a group of
processors - for instance via an ActorPath instead of a
processorId?
On Thursday, March 6, 2014 10:07:16 AM UTC-6, Ryan Bair wrote:
Thank you both.
On Thursday, March 6, 2014 2:13:48 AM UTC-5, Patrik
Nordwall wrote:
On Thu, Mar 6, 2014 at 8:08 AM, Martin Krasser
<[email protected]> wrote:
Hi Ryan,
On 05.03.14 21:35, Ryan Bair wrote:
I'm working on a project where I would like to
retain a history of actions performed against an
entity and then leverage that history for
business (what actions led the user to do X) as
well as providing the user with information about
past actions.
Event Sourcing seems like it would provide a good
way to accomplish this as the events are produced
and stored as a regular part of the application
flow, removing the need to do separate
bookkeeping. I'm really impressed by Martin's
work on the new Persistence module (and
Eventsourced before it) and would like to move in
that direction. However, I don't see a way to
query the `journal` other than through recovery.
Does it make sense to grow Persistence in this
direction, or is there a better way to tackle
what I am attempting? Perhaps simply querying the
underlying data store directly?
Generating query/read models (by projecting an
event stream onto an in-memory data structure,
tables in a database, or whatever) is an
application-level concern. Akka-persistence is not
meant to be a database with a query interface.
Seems that Datomic is closer to what you're
looking for.
Just as a point of clarification, I'm looking to query the
events themselves, not the resulting state.
I agree, and would like to add that you can use a
persistent View to replicate the event stream to the
query side, and there store a representation that is
optimal for these queries (e.g. in sql database).
/Patrik
I'm thinking I'll go this way and query the database
directly. I might make a JDBC/slick journal implementation
and use database views for the queries.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives:
https://groups.google.com/group/akka-user
<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
<http://groups.google.com/group/akka-user>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
Martin Krasser
blog:http://krasserm.blogspot.com
code:http://github.com/krasserm
twitter:http://twitter.com/mrt1nz
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> Search the archives:
https://groups.google.com/group/akka-user
<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
<http://groups.google.com/group/akka-user>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
Patrik Nordwall
Typesafe <http://typesafe.com/> - Reactive apps on the JVM
Twitter: @patriknw
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
<http://doc.akka.io/docs/akka/current/additional/faq.html>
>>>>>>>>>> Search the archives:
https://groups.google.com/group/akka-user
<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] <javascript:>.
To post to this group, send email to [email protected]
<javascript:>.
Visit this group at http://groups.google.com/group/akka-user
<http://groups.google.com/group/akka-user>.
For more options, visit
https://groups.google.com/groups/opt_out
<https://groups.google.com/groups/opt_out>.
--
Patrik Nordwall
Typesafe <http://typesafe.com/> - Reactive apps on the JVM
Twitter: @patriknw
--
>>>>>>>>>> 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]
<mailto:[email protected]>.
To post to this group, send email to [email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
Martin Krasser
blog: http://krasserm.blogspot.com
code: http://github.com/krasserm
twitter: http://twitter.com/mrt1nz
--
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.
