On 06.05.14 18:21, Ashley Aitken wrote:
Thanks again Martin.
On Tuesday, 6 May 2014 14:37:48 UTC+8, Martin Krasser wrote:
Good so I am on the write track. I am confused a little about
the Views keeping stage in memory and with snapshots. What state
would this be? Surely the read model itself is maintaining most
of the state, e.g. in a database. Could the Views themselves
sometimes be the read model that were queried by the client? Is
that meant to be the primary approach or not?
Yes, this is meant to be the primary approach.
So, please correct me if I am wrong, the View(s) are a front for the
read model, which is stored either 1) inside each View object's state
or 2) in a hidden backend store? Which one of those is most common?
Or something else?
Most common is 1, because state is automatically re-created when the
view is (re)started. Views could also use channels to update a backend
store (2) if you want but it's usually more efficient if processors do
that directly (see below).
Views that track updates from many processors make absolutely
sense and have already been requested several times (see ticket).
I won't ask when we can hope for a solution but I will ask (not
necessarily you but anyone reading) what are people doing until
then?
There are several options, some are
- Let the backend store (Cassandra, MongoDB or whatever) update
custom views (e.g. database tables) whenever a new message is
added to the journal (using triggers).
Are you talking about the backend store for the journal (for which
LevelDB is the default)? And that when a new event is added to the
backend store / journal a trigger fires that updates custom
denormalised entries for the read model?
Yes.
- Let processors update a database directly to create a view (via
channels to avoid duplicates during replay).
I'm not so sure I understand this one. Let the Processor update the
domain model AND the read model backend store? I guess that's
possible if it is on the same node.
No, there's no need to have the read model backend store on the same node:
- either use a local channel destination with a remote connection to the
read model backend store
- or a remote channel destination that connects to the read model
backend store.
And use a Channel to ensure the read model doesn't get redundantly
updated.
Yes (and channels additionally provide at-least-once delivery semantics).
Processor =Channel=> Actor (which is the read model or updates the
backend store)?
See above.
Cheers,
Ashley.
--
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.
