Stream MetaData & Projections

EventStoreDB
1

Given streams account-21, project-x, project-y, and project-z such that project x,y,z belong to account-21?

What is the best way to correlate every event in project x,y,z to account 21?

I can see how using stream metadata might be a viable (per http://docs.geteventstore.com/http-api/3.5.0/stream-metadata/ )

  1. Should I use stream metadata on project-x, y & z?

  2. Is Stream metadata available to projections?

  3. How is Stream Metadata any different from CRUD?

  4. Should I instead just make sure every event in project x,y,z references account-21?

Thank You,

Jeff :slight_smile:

2

The last one.

3

Would there really be a benefit to making all events in the project streams reference their owning account? Presumably (assuming a project cannot be moved between accounts), only the first event in those streams (e.g. NewProjectCreated or similar) needs to reference the account that owns them?

Then, it would be the role of a read model to be able to look up the owning account from an arbitary project id

4

Yes, it saves you from having to create extra lookups. Say an account could generate 15 different kinds of events. What if in the future you had a projection that was only interested in one of them? Now for each of these projections you have to handle an extra event and create a lookup.

5

Tradeoffs both ways!

Classic denormalization discussion.

6

OK, my wording was wrong. I can see the benefit to it, but I guess it feels dirty to me.

My issue with it is that you would be putting data on the event that isn’t actually part of the change that was made, because something else needs to know that data.

For example, let’s assume for the sake of argument that a single “user” can have multiple “accounts”. What happens when a consumer of a project event needs to know the email address of the user who owns the project? Would we add userId to each project event too, so that this consumer can then look up the user from a project event?

Adding the account id to each project event seems like we are polluting the event for the sake of convenience to avoid building a read model (which is what this lookup feels like it should be, to me)