Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC some constraints on metadata and event stream names #191

Closed
prolic opened this issue Oct 24, 2016 · 3 comments
Closed

RFC some constraints on metadata and event stream names #191

prolic opened this issue Oct 24, 2016 · 3 comments

Comments

@prolic
Copy link
Member

prolic commented Oct 24, 2016

I want to propose some changes here:

  1. Move aggregate_type and aggregate_id to event metadata. This is really only needed in special case that one stream per aggregate is not used. With that change we can have a unified event stream structure independent of which stream strategy is used.

  2. All internal metadata should be prefixed - I propose the underscore _ for this. This means all internal metadata (currently this would be: causation_id, causation_name, aggregate_type and aggregate_id) will be prefixed with underscore. Userland metadata is forbidden to use the underscore as first character of their metadata as it's reserved for internal usage. I don't know yet if an exception is necessary or if a note in the docs to strongly discourage it is enough.

  3. All internal streams like for stream-projections and so on (see: RFC stream to stream projections #193) will be prefixed with an underscore _, too. All userland streams are required not be begin with underscore as this is reserved for internal useage. Again: I don't know yet if an exception is necessary or if a note in the docs to strongly discourage it is enough.

@codeliner
Copy link
Member

I'd go for the note in the docs, otherwise we would need to check each metadata key. People should be familiar with conventions because frameworks use this a lot to make things easier.

I like the idea but we need to provide migration paths. Upgrading to the new major versions will be work and people need to be aware of that.

@prolic
Copy link
Member Author

prolic commented Oct 25, 2016

I am thinking of providing a migration script for the database using the event store api, so it should work for all adapters without providing special migration scripts for every database vendor.

@sandrokeil
Copy link
Member

Sounds really good and make also things easier for new people, because of less necessary fields.

@prolic prolic mentioned this issue Mar 24, 2017
@prolic prolic closed this as completed Mar 30, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants