linkTo in eventsourced processmanager

EventStoreDB
1

The PMs I have are almost like aggregates.
Instead of methods with parameters, they handle events though. First versions I saved the events straight off.
Next version I extracted all data and raised a new event “EventXHandled” with that data, since I didn’t want confusion about events (yes, different streams, but still). But this seems like unnecessary duplication of data.
Can I somehow just link to the event so that when I save the PM to eventstore it’s still an “EventXHandled”, but with link to the original event?

2

A linkto event points to another event and when read with resolve linkto will just read as that event. There are examples on the list and quite a few in tests. I can link you directly if you need tomorrow

3

Here is how you can write your own link to

new EventData(
Guid.NewGuid(), EventStore.ClientAPI.Common.SystemEventTypes.LinkTo, false,
Encoding.UTF8.GetBytes("###@stream"), null))

Cheers,

Greg

4

Thanks! I was just now writing these lines below:

5

Can’t access the internal class SystemEventTypes though.

Btw, why not json? (false param)
So, the byte[] data param, is it supposed to be the name of the event, like: “176@QuestionAsked”?
That will be enough for ES to link to that actual event?

6

shoot…name of the STREAM even

7

I copy / pasted from tests.

It’s in client api … It’s public in dev dunno without looking for a given type. That’s just a constant for the event type.

Basically set the event type and the data is ####@streamname

8

append only in this list is not to my liking… I’d really need to edit my posts sometimes to not confuse everything up.

Yeah true, constants.
Thank you very much.

9

// If this EventStore.ClientAPI.ResolvedEvent represents a link event, the Link
// will be the EventStore.ClientAPI.ResolvedEvent.OriginalEvent, otherwise it
// will be the Event
Just to be 100% sure (because I interpret the comments in several ways):
When I get the aggregate (event sourced saga/processmng) that is event sourced with linked events only,
do I need to change this part below to evnt.Link.Metadata and evnt.Link.Data? Or will the OriginalEvent always only be a reference to either of the two, and if it is a linked event, then the reference is to Link?
foreach (var evnt in currentSlice.Events)
aggregate.ApplyEvent(DeserializeEvent(evnt.OriginalEvent.Metadata, evnt.OriginalEvent.Data), true);

From:

StreamEventsSlice currentSlice;
do
{
var sliceCount = sliceStart + ReadPageSize <= version
? ReadPageSize
: version - sliceStart + 1;
currentSlice =
await _eventStoreConnection.ReadStreamEventsForwardAsync(streamName, sliceStart, sliceCount, false);
if (currentSlice.Status == SliceReadStatus.StreamNotFound)
throw new AggregateNotFoundException(id, typeof (TAggregate));
if (currentSlice.Status == SliceReadStatus.StreamDeleted)
throw new AggregateDeletedException(id, typeof (TAggregate));
sliceStart = currentSlice.NextEventNumber;
foreach (var evnt in currentSlice.Events)
aggregate.ApplyEvent(DeserializeEvent(evnt.OriginalEvent.Metadata, evnt.OriginalEvent.Data), true);
} while (version >= currentSlice.NextEventNumber && !currentSlice.IsEndOfStream);

10

Have you tried just reading an event to answer your question?

.event will point to what you want it will be the event of a linked event or the regular event of a nonlinked event

11

I added some documentation on ProjectionsManager and UsersManager to
docs today (they are PRs but will be accepted at some point).

12

(First of all, original and linked event, I do get confused about the meaning. Original to me should be the first that has happen, the one the link points to.)

About LinkTo: if I want the position of the first event recorded, how to get it?

In the RecordedEvent, there is the OriginalPosition, I guess that is the position of the second event (“Link”) but the first event (“Event”) has no position data.

Is it possible to get it? Or maybe the OriginalPosition is actually the position of the “Event”?

13

In the context of a subscription, the Original event is the one which caused the subscription to fire, which may well be the link. If you’re checkpointing you want the thing that caused the subscription not the thing it references.

14

Hm, OK…
Maybe I need to reconsider using linkTo when eventsourcing processmanagers.

I’ve used the position to ensure idempotency for readmodels when subscribing to events. Don’t want to write same event twice as the linkTo event shows up.

IsResolved property will only be true if the event has a reference to another event, i.e. is a linkTo, right? So I can differentiate on that property.