Hi Andrew,
although your strategy to anticipate sequence numbers will work, I
recommend you to use your own counter and make that counter part of your
(Eventsourced)Processor's state. This will not only make you independent
of sequence number assignment implementation details but also allow you
to implement logical time so that you can make assertions about
causality of messages/events that have been processed/generated by
several processors. Implementing logical time may require to set counter
values based on incoming messages (and not just incrementing it by 1). I
think this is what Viktor refers to when saying it "precludes
distributed event generation" but I may be wrong here.
Whether or not counter values should be included into events before
persisting them really depends on your use case. If you only want to
make assertions about the ordering of events generated by a single
EventsourcedProcessor, you could also re-use the sequence number of the
currentPersistentMessage and update the event after persistence but
before publishing it or applying it to current state. This would free
you from anticipating sequence numbers, from sequence number assignment
implementation details and even from maintaining your own
application-specific counter.
Hope that answers your questions.
Cheers,
Martin
On 22.12.13 21:17, Andrew Easter wrote:
I'm not really sure I understand. If akka-persistence has to choose,
prior to persistence to a journal, a sequence number to associate with
a payload, it's surely, to some degree, a nuance of the API design
that prevents me knowing, in my implementation, what that sequence
number would be? Whether the sequence number is available within my
payload, or as part of the actual serialised object (PersistentRepr)
that wraps my custom payload, I can't see how it changes the fact that
the sequence number must be explicitly passed to the journal.
If I'm missing the point, I'd appreciate learning where the limitation
exists in my understanding.
On Sunday, 22 December 2013 12:23:20 UTC, √ wrote:
That precludes distributed event generation.
On Dec 22, 2013 6:13 PM, "Andrew Easter" <[email protected]
<javascript:>> wrote:
Hi Martin/others,
When using EventsourcedProcessor, whilst the underlying
persistence mechanism will associate a sequence number with
any event persisted, I still see some value in being able to
persist the sequence number within the custom event payload.
For example, say I have an event payload such as:
case class Event(id: UUID, correlationId: UUID,
sequenceNumber: Long, data: Any)
- id = the unique id of an aggregate root
- correlationId = the correlation id of the command that was
executed to spawn the event
- sequenceNumber - the sequence number of the event for the
given aggregate root
- data - the internal payload which would vary depending on
actual event that has occurred in the system (e.g.
CustomerCreated)
Using EventsourcedProcessor, I'd like to pass such a
representation to the persist(...) method. However, at that
point, the only way I can determine what sequence number will
be persisted with an event is to take the current sequence
number and increment by 1 - if I am persisting multiple
events, I'll have to increment by 2, 3, 4 etc.
I am okay to anticipate the sequence numbers prior to
persistence? Also, do you think I'm being unnecessarily
pedantic to want to keep everything related to an event within
my own payload?
Thanks,
Andrew
--
>>>>>>>>>> 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] <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>.
--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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/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
---
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/groups/opt_out.
