Hi
From your question it looks like you want to build up a persistent view by
merging journal streams using multiple persistence ids. That is a common
use case and my experience is that is is a bit cumbersome, but doable today.
However you want strict replay ordering over multiple persistent
Hi Roland / List,
I am looking into an addition/mutation to the Persistency layer that allows
storage of an aggregateId (more or less the whole 'tag' idea without being
able to have multiple tags to start out with) with a replay (for the view)
based on that aggregateId. (bit like the DDD
Well,
I found that the sequence numbers are actually generated on a per
persistent actor instance basis.
So that makes replay for a single aggregateId based with limits on the
sequence numbers a bit of an intresting challenge
Still interested in your opinions as that will have impact on the
Hi Murali,
I started development of an application based on Akka Persistence to
implement CQRS concepts about a year ago. A lot of ideas came from
different topics in this group. Recently I started to extract a small
library from this application. The approach I took is to redundantly store
Hi Murali,
the core team at Typesafe cannot work on this right now (we need to finish
Streams and HTTP first and have some other obligations as well), but Akka is an
open-source project and we very much welcome contributions of all kinds. In
this case we should probably start by defining more
Maybe in 'The Reactive Manifesto' v3.0:
The human user as an auxiliary part of a reactive system should be
responsive, resilient, elastic and message-driven too. He may be the
weakest link in the chain.
W dniu piątek, 9 stycznia 2015 11:56:40 UTC+1 użytkownik Greg Young napisał:
Usually it
Thank you Greg. The mind shift from a preventive to a reactive workflow is
not easy for users (humans), because it requires a change of habits. For
many people computer systems are kind of authoritative. There is this wrong
assumption (from early days of computation?) that a computer accepts
Usually it comes down to the realization that the computer is not the book
of record. One of my favourites was being asked to build a fully consistent
inventory system. I generally like to approach things with questions, the
one i had was 'sure but how do we get people who are stealing stuff to
On Fri, Jan 9, 2015 at 11:56 AM, Greg Young gregoryyou...@gmail.com wrote:
Usually it comes down to the realization that the computer is not the book
of record. One of my favourites was being asked to build a fully consistent
inventory system. I generally like to approach things with
That is a great point Greg.
On Wed, Jan 7, 2015 at 10:15 PM, Greg Young gregoryyou...@gmail.com wrote:
The consistency of the query model should be achieved as soon as
possible and close to real-time.
It really depends on the domain. I have worked in many situations
where the data in
Hi Vaughn,
from our side nothing has happened yet: my conclusion is that this thread
contains all the information we need when we start working on this. The reason
why we are waiting is that this work will depend heavily upon Akka Streams and
therefore we are finishing those first, which
Hi Markus,
thanks for this very thoughtful contribution! [comments inline]
31 aug 2014 kl. 15:05 skrev Markus H m...@heckelmann.de:
Hi Roland,
sounds great that you are pushing for the whole CQRS story.
I'm just experimenting with akka and CQRS and have no production experience,
but
Attempting a second round-up of what shall go into tickets, in addition to my
first summary we need to:
predefine trait JournalQuery with minimal semantics (to make the Journal
support discoverable at runtime)
predefine queries for named streams since that is universally useful; these are
On 05.09.14 09:09, Roland Kuhn wrote:
Attempting a second round-up of what shall go into tickets, in
addition to my first summary we need to:
* predefine trait JournalQuery with minimal semantics (to make the
Journal support discoverable at runtime)
* predefine queries for named
Hi Roland,
This will certainly simplify my code. So from my side it will be a good
'start' to experiment with these additions in practice and see what's
missing.
Kind regards,
Olger
On Friday, September 5, 2014 9:49:20 AM UTC+2, Martin Krasser wrote:
On 05.09.14 09:09, Roland Kuhn
5 sep 2014 kl. 09:49 skrev Martin Krasser krass...@googlemail.com:
On 05.09.14 09:09, Roland Kuhn wrote:
Attempting a second round-up of what shall go into tickets, in addition to
my first summary we need to:
predefine trait JournalQuery with minimal semantics (to make the Journal
Hi Martin and Alex,
the point you raise is a good one, I did not include it in my first email
because defining these common (and thereby de-facto required) queries is not a
simple task: we should not include something that most journals will opt out
of, and what we pick must be of general
On 28.08.14 12:00, Roland Kuhn wrote:
Hi Martin and Alex,
the point you raise is a good one, I did not include it in my first
email because defining these common (and thereby de-facto required)
queries is not a simple task: we should not include something that
most journals will opt out of,
Hi Roland,
On Thursday, August 28, 2014 11:00:17 AM UTC+1, rkuhn wrote:
Concerning types I assume that there is an implicit expectation that they
work like types in Java: when I persist a ShoppingCartCreated event I want
to see it in the stream for all ShoppingCartEvents. This means that the
Dear hakkers,
there have been several very interesting, educational and productive threads in
the past weeks (e.g. here and here). We have taken some time to distill the
essential problems as well as discuss the proposed solutions and below is my
attempt at a summary. In the very likely case
20 matches
Mail list logo
