Why no CausationId?

[Luis Ferrao]

Been reading the doc and I see CorrelationId but no CausationId, is this a deliberate decision? If so, why? Note that it's very likely I would know this if I were more experienced in ES.

[Roman Provazník]

Hi @LFerrao,

no problem at all :) From what I understand the difference between CorrelationId vs CausationId is that CorrelationId lets you to see all related events, where CausationId is the Id of the initial event (that caused new events created).

Since in this library everything is in developer's hands, it is up to you, how you use this field. You can use Id of triggering event as CorrelationId for chained events so initial event Id is the causation one, and chained events can be correlated by that.

I personally do it rather this way:

1. I have new event to write into store
2. Generate new Guid as CorrelationId
3. Use this CorrelationId for any other events that happened as result of first one
4. Now I have first event + any chained stored under same CorrelationId, so I can see whole conversation.

What do you think about it?

[Luis Ferrao]

I agree that it doesn't seem like you're losing data by not storing it.

Regarding my oppinion I'm not sure I feel uncomfortable leaving it here as I literally just started learning about the topic (both ES and F#), but it's my understanding that an event should have 2 IDs in addition to its own (3 total) from what I read from Greg Young. The correlation ID is the original event ID (allowing to get an entire event tree with a single ID since all messages of the tree share the same correlation ID), and the causation ID is just the ID of the previous message.

Granted, with this definition it seems like you could get one with the other, albeit with some extra query gymnastics and I guess extra RSU cost as well.

[Roman Provazník]

I think you got point here - the correlationId is good for grouping related events, but the tree view is missing here. I will think about it for next release, however need to think about it more from two perspectives:

• it would be breaking change (or it would have to be optional)
• there is no function for getting events based on correlationId (yet)

[Luis Ferrao]

I realized reading your message that what I said can't be correct. I said you can get one with the other but in fact without CausationID you can't tell if two events were caused by the same (parent) event and are in fact siblings as opposed to all three being caused linearly one after following another. I mean similar timestamps can indicate it but that's really not a proper or reliable way to tell. You really need both correlation and causation as far as I can tell.

[Roman Provazník]

Yes, that would be handy. I'll think about it for new version definitely.

[Roman Provazník]

FYI, I am about to release version 2 soon (tomorrow or day after tomorrow most likely) with having both CorrelationId & CausationId. Also from v2.0.0 each CosmoStore implementation will be in separate package where CosmoStore is only API definition.

• https://www.nuget.org/packages/CosmoStore/2.0.0-beta1
• https://www.nuget.org/packages/CosmoStore.TableStorage/2.0.0-beta1
• https://www.nuget.org/packages/CosmoStore.CosmosDb/2.0.0-beta1

[Luis Ferrao]

That's pretty awesome! Unfortunately for me, I had to stick with Postgres for the backing store along with some additional weird requirements like having to rely on FSharpLu's serialization, so I ended up writing my own poor man's store that's clearly never meant to be battle-ready, but I did use the opportunity (if it can be calle that) to familiarize myself with CQRS.

[Roman Provazník]

No problem, the CosmoStore.Postgres will be probably the next package 😄

[Roman Provazník]

Aaaaaaaaaaaand it is published and docs updated. Thanks for hints! 🙏