These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
@krasserm: Into an
ORSetService[A]I can put things of type T, the wishlist items as you suggested. But in addition I would like to save more metadata for a wishlist like: userId it belongs, is it public or not and a name for it. To me it seems I want an aggregate like this:
case class WishlistItem(variantId: VariantId, name: String) case class Wishlist(userId: String, name: String, items: Vector[WishlistItem])
As far as I understand the ORSet I can not model this ?!
I’ve got another question regarding deletion of events. We also want to persist wishlist items for anonymous users which might get turned into real ones for a logged in user. That means that I would collect wishlists for anonymous users which might get obsolete i.e. after the session times out. Looking at http://rbmhtechnology.github.io/eventuate/reference/event-log.html#deleting-events it’s not possible to delete those aggregates from the log when I use the C* backend. Does that mean I need to keep them forever?
Maybe I do not use EventSourcing for those aggregates and just persist them in the database or I live with those obsolete events which might be actually fine but depends on usage, etc. Not sure yet.
As @gabrielgiussi already mentioned, I'd also model
Wishlist separately from the mutable list of items, assuming the metadata are immutable i.e. are only created but never updated. For example
case class Wishlist(userId: String, name: String, itemsCrdtId: String)
defines the wishlist metadata and references the items CRDT by id. A service that wants to update the wishlist for a user should first find the wishlist by userId from a view and then update the CRDT with the obtained
orSetService.addrepresents a command and should therefore not be executed by an event handler. I know, it's idempotent in this case but still not recommended design.
Can be a CRDT part of a EventsourcedActor's state?
Sure, all CRDT services are implemented like that as mentioned in http://krasserm.github.io/2016/10/19/operation-based-crdt-framework/
What if the metadata is mutable
Then consider implementing the whole aggregate as custom CRDT with the CRDT development kit (see above link), or, if you want to work with the lower level actor API you can make CRDTs part of the actor state but then you re-implement logic that is already defined in the abstract
consider implementing the whole aggregate as custom CRDT.
Ok, I will give it a try to this approach when I have time, meanwhile I'continue working in an example where I've taken the approach proposed (Actually, I was between the two approaches a weeks ago). I will upload the example to github in a couple of days.
if you want to work with the lower level actor API you can make CRDTs part of the actor state
You mean hold an ActorRef to a CRDTActor in my EventsourcedActor and send it the commands that are currently being send by the service? If I understood correctly this will mean making CRDTActor class public.
WishlistItemAdded) instead of the pre-defined operations in the eventuate-crdt module.