These are chat archives for RBMHTechnology/eventuate

15th
Dec 2016
Volker Stampa
@volkerstampa
Dec 15 2016 08:46
@danbim You are right, the current API does not permit to define custom aggregate ids when processing events in an EventsourcedProcessor, however I do not see a reason why this should not be possible. Feel free to open an issue for this. PRs are also welcome :-).
Daniel Bimschas
@danbim
Dec 15 2016 09:20
Will do PR, then :)
Thanks @volkerstampa !
Volker Stampa
@volkerstampa
Dec 15 2016 10:04

@fkoehler Let me try to answer your questions:

  1. Physical deletion from C* is also on our wish list so we assume to tackle this within the next months. No promises, though, as priorities might change.
  2. If you delete events bypassing eventuate, unexpected things might happen. If you do not use replication at all it should be safe to physically delete logical deleted events, however in combination with replication you might unexpectedly lose events. See also RBMHTechnology/eventuate#314 for a discussion on potential effects of event deletion in a replication network.
  3. A single event log must only be accessed by a single event log actor. If multiple nodes want to exchange events over a single log, they must use replication (making this a replicated log). So to me it sounds like you should use ReplicationEndpoints anyways.
  4. Currently logical deletion of events in C does not store the ids of remote replication endpoints events must be replicated before physical deletion. So once physical deletion in C is supported it could make sense to issue the delete request once again to trigger physical deletion.

Regarding your generic question:
As you already found out it is really not recommended to use java serialization in production. Just like akka itself we are successfully using protobuf in our projects. Regarding "out of the box" akka serialization, you might want to have a look at External Akka Serializers, however "out of the box" solutions might not be ideal when it comes to schema evolution. Regarding schema evolution you might also want to have a look at RBMHTechnology/eventuate#224 where upcoming changes in Eventuate are described.

Fabian Koehler
@fkoehler
Dec 15 2016 10:16
@volkerstampa Thanks for the answers. That helps a lot.
Marco Ehrentreich
@mehrentreich
Dec 15 2016 16:46
hi guys
I'm trying to figure out what the purpose of the globally unique id (not aggregatedId) of an event-sourced actor is
and for which use cases an id might be required
I got this wrong at first but everything seemed to work as expected despite having defined a proper id for each actor or view
Marco Ehrentreich
@mehrentreich
Dec 15 2016 17:28
btw. of course I found the part in the documentation which states that each actor has to have a globally unique id but I couldn't find any explanation regarding the purpose of the id