These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
EventsourcedActors within a shard. If you additionally want to have cross-shard event collaboration you need to connect the shard-specific local event logs to a replicated event log. If you don't need event collaboration between
EventsourcedActors but only want to aggregate events from all shards into a single log (for creating views, for example) you could connect the shard logs to an aggregate logs and run
EventsourcedWriters there. Hope that helps.
Hi! i am fairly new to functional programming, event sourcing or even scala programming (since i had been working mostly on Android development in Java over the past years). But i have been studying a lot on the past months in order to select a technology stack for rewriting a backend for an app and i have decided to choose event sourcing with eventuate as the persistence layer for the project :).
I think i have read most (if not all) the documentation i have found on eventuate but i still have several doubts about the proper/best way to do some things and maybe you could give me some advice. The part i am stuck now is how to assign ids to entities or aggregates and how to assign them to actors.
The example application, for instance, uses manually assigned ids for the orders and it can easily forward each order to an actor based on that id (since it is known from the very beginning). But in my case the data is coming from external systems and in the current backend the entity id is retrieved from several possible queries to the database based on the parsed data from the external systems (the parsed data is also often incomplete which is the reason for the alternate queries). If a row is found by these queries, the new data is considered to be for the same entity (with its corresponding id). If none of the queries have a result, a new entity (with an auto incremented id) is added to the database.
The example application on eventuate also has a querydb package that creates customer ids by incrementing a counter, although the tutorial seems to be missing an explanation on that part of the eventuate-examples. Despite that, that approach seems to be a good alternative for the auto incremented ids of the relational database on the current backend although i probably need to include on it the queries for previous entities and not just the incremental counter. Therefore, my question is how to do that.
So far, my best idea is to have the full state for all the entities in this actor (an actor equivalent to the Emitter actor of the querydb example) but i am not sure if that is a good practice. Another alternative may be to query another view from this actor and then forward the events to additional actors for each entity once i know their ids.
Finally, the ids i have now are integer/long ids, but the actors on eventuate require unique string ids. Is there a recommended policy for assigning entity ids to actor ids? There are also more than one entity types on the same backend that currently have integer ids too, so a simple conversion of the ids to string may not be good enough.
What do you think? Any tips?