$streamcreated and backwards compatibility

EventStoreDB
1

We have been looking a lot at how stream metadata is working (things like maxcount and maxage). This is also involved with the addition of acls for streams. As of now the first event in a stream is the $streamcreated. This seems to have caused confusion for many.

We are considering moving this event to another stream $${stream}. This would allow for a few things to be done in a much more coherent manner (updating is far simpler). The client API as an example would have an “update stream metadata” method and would also have all methods.

In making this change we would ideally remove the $streamcreated event from the original stream. This is however a breaking change. We can support backwards compatibility here but it will end up being a touch awkward API wise. In particular the $streamcreated would be written to two places. It being in the stream also seems to confuse many people (we have had at minimum five emails on this list with people getting confused by this).

As such we wanted to discuss with the community whether or not you depend on the $streamcreated event. We have seen a few pieces of code that specifically ignore it, this would simplify those bits of code. Are you currently using this event for anything today?

Cheers,

Greg

2

+1 for removing the event. For me a stream contains only events that are relevant for the application/the business processes.
The $streamcreated event definitely belongs into its own stream since it is an infrastructure related thing.

3

I actively ignore that event, but don’t mind it being there.

4

We don’t use EventStore in production, but would like to before long. I agree with Mr. Schenker – why should “my” event stream contain “your” bookkeeping?

5

+1 for removing

6

Another +1 for moving to a different stream. I’m ignoring $streamCreated atm but will need it soon, but I’m happier it doesn’t come as part of the ‘created’ stream itself. Break away.

7

+1 Remove please. I prefer breaking changes at this early stage of the product life-cycle. It will only become harder as the product becomes more popular.

8

I’m for removing it as long as there’s an upgrade path/guidance for an older db.