These are chat archives for RBMHTechnology/eventuate
Global-scale event sourcing and event collaboration with causal consistency
hi @krasserm we are using eventuate in our project an are stuck in one use case scenarios.
Eventuate is best when we logs the events and they are replayed to the current state , but we are not able to query it directly from the event_store.
Ill explain using a scenario : -
Suppose we have user details with us as Email ,
now when any user updates his email we log an EVENT as EMAIL_UPDATED , with content as new emailID .
again user can update his/her email anytime and each time new EVENT is Logged. now my question is :-
1) How do I fetch the no of times any users has updated the email on a particular Day?
2) How will I get any user updated Email content for any particular data/time ?
Now I need to get these details using the EVENT_STORE , means how can i query directly to the event_store ?
Currently we are maintaing the current state through EventSourceView in memory, that is the current updated details for the email ,
but my aim is to get the history for a particular event (like updated Emails).
I have searched a lot on net but didnt get any solution , also on one of the ticket ' RBMHTechnology/eventuate#88 '
it is mentioned that it not possible using the eventuate to query and fetch directly from event_soure.
So the only solution I am thinking is I need to maintain all the possible state for the particular event in memory which is not fesible in any case.
Please suggest if there is any way to overcome this problem ,
Waiting for any early positive reply , Thanks in advance
GetResultsvia a message. The EV would be stopped afterwards.
Also I have one doubt , if we use EventsourcedWriter to log into external Cassandra DB , then to retrieve the results we have to write separate CQL queries , as I think Eventuate dosen't provide any EventsourcedReader or any such thing
EventsourcedWriter reads a the event history and creates application-specific current state. What would you expect from an
EventsourcedViewthat's "configured" with some kind of query/aggregation "strategy" during construction, that the EV can then apply during event replay to build the query specific view on the events. Such an EV would only exist for the lifetime of the query, afterwards it would be destroyed.
Flows without exposing
DurableEventmetadata to the user. But
Flowinput and output must be related to these metadata in order to preserve causality. More on that later in the user documentation.