Writing stream metadata before the stream has been created

EventStoreDB
1

Using the .NET client, is it possible to write a stream’s metadata before the stream has been created and have it take effect when the stream is created? If I understand things correctly, a stream isn’t created until at least one event has been written to it. So, in order to write the metadata, you’d have to wait until at least one event has been written to the stream which makes things awkward in some cases. I’m trying to store some checkpoints in a stream, and I’d like to set the maxcount to 2 so that I don’t end with a huge stream full of checkpoints. I’ll only ever need the latest one anyway. I’ll only need to set the metadata once, but it feels weird having to wait for that first event to come through just so that I can set the metadata.

2

Yes, you can set the stream metadata before the stream is created. It’s stored in a separate stream ($$streamName) so has no effect on expected versions etc.

3

Thanks! That makes things a lot easier.

4

I assume you can’t write a sentinel event first as part of your metadata activity? Personally, philosophically, I really don’t like to alter streams in that way, it is sometimes an anti-pattern in event sourcing. I’m sure you have a reason, if you’d explain that would satisfy my curiosity.

-Sam

5

I’m just using the stream for storing checkpoints (ES positions) for a single message processor running in a .NET process. The state of the processor object only consists of the last checkpoint (ES position) of the last message it has processed. I don’t really care about everything going on with the processor, i.e. storing an event every time it starts running or shuts down, and since the processor will be processing every single command and event that pass in and out of my system, I don’t really want to be storing a potentially infinite stream of checkpoints, especially when I only care about the last one or two. It’s information that will never be of any use to anyone.

6

I see. Since you aren’t processing INTO a persisted read model, then I can see why you’d rely on ES to store checkpoints. We use persisted read models, and atomically commit the checkpoint and update together. This prevents accidental replay if the processor itself fails between doing work and updating the checkpoint.

Makes sense, thanks!

-Sam

7

Yep, and I have a separate process that does exactly what you are talking about as well. What I am trying to do ES as my “bus” for commands and events.