Discussion of StreamId or AggregateId in Event

[petersondrew]

I'm looking into implementing an IEventStore for other event stores (such as Greg's EventStore, or StreamStone, et al), and one of the requirements for those storage backends is that the stream or aggregate id be used to persist the event.

Based on the current signature of IEvent, that is not possible. Would you be open to accepting a PR with AggregateId added to the IEvent signature? It may also be easy enough to just add the aggregate or stream id as an argument to the IEventStore Get/Save methods.

Any thoughts on this? Thanks!

[petersondrew]

On close inspection, AggregateId is already an argument to IEventStore.Get, so perhaps adding it as an argument to Save is the path of least resistance here?

[gautema]

AggregateId is already on IEvent. It's just called id. Do you need it as an argument to save as well?

…

On 6 Jun 2017, at 00:36, Drew Peterson ***@***.***> wrote: On close inspection, AggregateId is already an argument to IEventStore.Get, so perhaps adding it as an argument to Save is the path of least resistance here? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[petersondrew]

Ah, for some reason I was thinking that that was the unique event id in that context. If that is already the aggregate id then I have everything I need already. Oops.

[andrewmurray]

@petersondrew I'm curious as to how you got on with you implementation of Event Store with CqrsLite. Don't suppose you've read my issue #34 ? Did you have any problems with aggregate version concurrency?