It is a subset of the approach. It is useful in a narrow subset of situations.

Sure. I would just as soon do that in the applicative code as the database code. I wouldn’t say it’s a preference, but writing, running and managing tests without have a database involved is something that I would value much more than putting this kind of thing in the database.

We tend to accumulate into some entity that is specialized for the kind of projection. We read the stream, project into the entity, and cache the entity. Verifying the projection is a matter of merely instantiating an entity, sending whatever event through the projection implementation, and verifying the resulting state.

So, given that model, I could make decent use of an event database that allows me — at a minimum — to replicate the kind of stream/category features that I use in Event Store (and that we’ve more-or-less reproduced using Postgres).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.