Why no CausationId? about cosmostore HOT 9 CLOSED

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

from cosmostore.

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

from cosmostore.

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?

from cosmostore.

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.

from cosmostore.

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)

from cosmostore.

from cosmostore.

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

from cosmostore.

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.

from cosmostore.

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

from cosmostore.