Using the node.js event-store-client. When calling readStreamEventsForward you get a structure called StoredEvent. There is one property here called eventNumber (it says “number” in the docs, but in my tests, it’s “eventNumber”).
If I run this method on a projection-generated stream with resolveLinkTos = true, then the “eventNumber” field is populated by the original linked stream’s event numbers. If I set resolveLinkTos = false, then I get my projection-generated stream’s event numbers (which I want!) but can’t access the linked event data.
I’m not sure if there’s any way I can get both the projection stream’s event numbers (which I need for keeping track of my read model) and the linked event data.
The workaround I might have to use for the short term is using emit(…) in my projection, instead of linkTo(…) to create copies of the events instead of references. Is there a better way?
In the .net client if you look there are two records when
resolveLinkTos=true
https://github.com/EventStore/EventStore/blob/release-v3.7.0/src/EventStore.ClientAPI/ResolvedEvent.cs#L19
my guess is the js client works similarly (its representing what is
actually sent over the wire).
Examined the deserialization code for both Node and C# client.
So a “resolved event” has a JSON structure sort of like this (irrelevant chunks left out…)
{
“event”: {
“eventNumber”: 0
}
“link”: {
“eventNumber”: 1
}
}
``
Based on stepping through the Node code when deserializing events from my projection stream (created using linkTo(…)), with resolveLinkTos=true, it would appear that it’s the “event.eventNumber” property which holds the linked event’s original number, and the “link.eventNumber” property which holds the projection event’s number in the projection stream (i.e. the one I want).
The Node client appears to ignore the “link: { }” structure entirely when deserializing. See event-store-client :: lib/connection.js - unpackResolvedEvent(resolvedEvent) -> return unpackEventRecord(resolvedEvent.event);
This appears backwards to me. Shouldn’t the “link” structure hold the original stream’s event number and the “event” structure hold the event number from the projection stream?
"This appears backwards to me. Shouldn't the "link" structure hold the
original stream's event number and the "event" structure hold the
event number from the projection stream?"
No as what is written to the projection stream is the "link". The
original event is the event.
To be fair we don't maintain the js client so I am just going off of
how it works in other clients.
Got it. That does make sense then. Going to try a pull request on the JS client.
Out of interest - why isn’t there an official Node client?
w
As a follow-up, my pull request was accepted. The event object now has an optional “link” property in the case described. This solved my issue.
I did a port of the EventStore .Net Client API.
https://github.com/nicdex/eventstore-node
API is exactly the same as the .Net Client.
The client is stable and should be in RC soon.