Read events - Position vs int

Hi there,

I’ve just noticed ReadAllEventsForward takes the Position for the starting point, but ReadEventStreamForward takes an int. Could someone explain the difference please?


ReadAllEventsForward is a special command that reads from the internal globally ordered eventStream and takes Position as input (and count as second parameter), this is dictated from the event-store internal transaction file architecture. For you it’s just a value object that represents a specific point inside the whole event-store.
ReadEventStreamForward reads events from a single stream so it just needs the point on the stream where you want to read from.

Ok great thanks for that. So I can just remember the event number instead of the position for recovering a stream. Cheers

Based on this I think I must be using projections incorrectly. I’ve got a projection that combines a bunch of streams into one other stream, which is what my denormalizer subscribes to. But it looks like if my denorm wants to catch up (read forward) with this projected stream it can’t - I get a StreamDoesNotExistException. I’m guessing there’s no way to specify the position of a ‘linked to’ stream?.


What is a name of the stream you try to read?

‘StaticEvents’ - It’s just a linkTo in a persistent projection that combines a bunch of events from different aggregate roots into one stream


actually it’s Static.Events (with a period).

Do you see your projection actually processed any events? (you can see it at projections screen, but unfortunately it shows only number of messages processed since last ES restart).

ah I know what the problem was, it was trying to subscribe before that projection had actually had a chance to run so linkTo hadn’t actually been called yet. Works fine now.

Thanks for the help :slight_smile:

Quick question: Does an eventType of $> mean it’s a linked event?

one more :stuck_out_tongue:

a while back Greg mentioned you were possibly starting work on pushing events out for linked events (so I don’t have to make a roundtrip to get the actual event from the linked event). any clue when that’s coming if at all?



The ReadStreamEventsForward class in the EventStore.ClientAPI.Messages in the dev branch has a ResolveLinkTos property, which indicates whether the link_to events should be resolved.

If they are resolved you receive both original link_to and target events in response. You need the original link_to event to track a position of your projection/reader.


hey, yeah I saw that. But there’s nothing on a regular subscription allowing me to resolve the target event (without doing a roundtrip back using the position)?