On 06.03.14 19:01, Mike 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 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?
Designing single-processor views was intentional because ordering of
logged messages is only defined for a single processor. There's no
global ordering of messages. Message/event streams from different
processors are unrelated. If you want to want make statements about
ordering/causality of messages across processors, you must provide
application-level means for that (vector-clocks, ...).
If ordering is not important for your use case, just setup n views and
send their received messages to an aggregator for example. Please note
that in this case, the ordering of messages received in a live stream
may differ from that in a replayed stream. Consistent ordering of
messages in live- and replayed streams is only guaranteed for a single
processor (or view).
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
>>>>>>>>>> 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/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://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.
