Projections and Reset Behavior

EventStoreDB V5.X
#1

Lately I have been playing with side-effecty projections that emit events onto some target streams. The dashboard rightfully warns me that resetting projects is a dangerous process because emissions will be fired again.

In my particular stream model, the extra emissions are acceptable so I was pleasantly surprised that these just worked the way I expected. To some extent.

One behavior that I did not expect though was that previous event emissions (prior to resetting the projections) on these target streams were deleted (hopefully soft-deleted.)

So my questions are: is this behavior correct? Did I hit some default setting? Can it be turned off?

A side question is: are events soft-deleted? I would really appreciate if events were “eternal”. :slight_smile:

Best,

Tiago

#2

Tiago,

I can be corrected if wrong, but I am fairly certain these events are soft deleted and will only be there until your next scavenge.

In my head, if you wanted to keep the original events, you would make sure the projection always persisted the data in the original evens before you emit the new one, so the old data is carried on to the latest emitted version.

Hope that makes sense.

#3

Thanks Steven. Do you know if this behavior can be turned off? We are trying to design our streams with the mindset that they are immutable and infinitely persistent so we would prefer not changing the past if possible.

#4

You would have to make sure you never reset the projections, but if these events are so critical, perhaps it’s pointing to an issue in the design.
These events could belong to an aggregate, rather than being constructed via a projection?
Generally, I would be using a projections for things that make querying easier.

#5

Steven, I think you nailed it. It’s an aggregate stream constructed via a projection. Is there another way to get aggregates without projections?

#6

On our systems, we use the antive code (C#) to build an maintain the aggregates.
These events would never vanish.
What are you currently using to write events?

#7

We are using HTTP since our clients are very diverse.

#8

So you post the events directly on the http interface?
What sits in front of this though, controlling whether the event should be created or not.