Asserting that stream exists in write (without specifying version)


I know that when writing to a stream, you can assert on the current version, which works well for mimicking transactions and for optimistic concurrency. I've also seen that you can assert on there being no stream, but not seen a way to assert that the stream does exist, without specifying a version.

Having this would be useful in some cases where you want to add an event to an aggregate, but don't actually care about its current state, e.g. adding a note. Rather than loading the aggregate from events only to validate that it exists, you could attempt the write and reject it if the stream was not already created.

Is support for this somethings that has been considered / could easily be added? If not, is there any particular reason why this would be a bad idea?


Right now I don’t believe there is a way to do this.

For the actual use case you suggested you could always read a single event to verify it exists. That said I’m not sure that an “Expected Version Any Provided Stream Exists” semantic is a bad plan. Perhaps @greg has more thoughts on this?


This seems like a reasonable use case. I am not sure how many would
actually use it but overall it seems reasonable. It should be pretty
easy to add as well. Maybe something like

That would be great, and exactly what I was looking for!

To be clear:


Requires: either metadata or an event have been written for a given
stream. (for more see definition of ExpectedVersion.EmptyStream)

One question I have is how does this interact with soft deletes? If a
stream has been soft deleted I would assume it no longer exists would
this be reasonable from your point of view?

Yes, for the scenarios I had in mind, I’d want to know that there is a stream that corresponds to an existing, non deleted aggregate, so I would expect to see a fail on an attempted write to a soft deleted stream.


Reasonable? If so likely in next release (3.6.0 is already out for
binaries and packages updating during the week) so it will be about a
month is that ok for you?


Many thanks, LGTM!

Timeline should not be a problem, we are just getting started with eventstore and can work around it with a preceding read for now.

How will this impact clients though? We will be using the JVM client.

There will just be a new constant introduced in the clients. If they
do not support it you will just be able to define it yourself and pass
it as expected version. As example:

WriteEvents(stream, eventdata, ExpectedVersion.Any)

WriteEvents(stream, eventdata, ExpectedVersion.StreamExists)

if they don't support it

WriteEvents(stream, eventdata, -7)

Perfect, that all works for me.

Will be in the next release.