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

Persistence of events as byte array #3

Open
alkampfergit opened this issue Jun 5, 2015 · 4 comments
Open

Persistence of events as byte array #3

alkampfergit opened this issue Jun 5, 2015 · 4 comments

Comments

@alkampfergit
Copy link

It would be probably better to handle persistence of events with low level format, such as byte[], but support a pipeline where the user can inject stages if needed (es. serialization, upgrading events, etc).

@mauroservienti
Copy link

  • may I ask why?
  • and better compared to what?

@alkampfergit
Copy link
Author

Instead of persisting Serialized object, it is related to Slack discussion, the long list of pain point from Damian, point 6. I'll report here for completeness.

  1. Pure OO api abstracts data to far away from the user. In comparision, EventStores byte[] based API may be too low level. I want (and I want people to want) to work with events as data . Having them expressed as objects should only be a convenience.

Byte[] can be too low level, but it could be nice to have a pipeline and letting the user choose format for their Events.

@mauroservienti
Copy link

+1, got it. Thanks

On Fri, Jun 5, 2015 at 9:49 AM, Gian Maria notifications@github.com wrote:

Instead of persisting Serialized object, it is related to Slack
discussion, the long list of pain point from Damian, point 6. I'll report
here for completeness.

  1. Pure OO api abstracts data to far away from the user. In
    comparision, EventStores byte[] based API may be too low level. I want (and
    I want people to want) to work with events as data . Having them
    expressed as objects should only be a convenience.

Byte[] can be too low level, but it could be nice to have a pipeline and
letting the user choose format for their Events.


Reply to this email directly or view it on GitHub
#3 (comment)
.

Mauro Servienti
Microsoft MVP - Visual C#

@andreabalducci
Copy link
Member

this way we can handle better upgrading / transformation because we are not forced to rely on class serialization (easy to broke).

With opaque serialization in place we can configure any pipeline

  Commit => byte[]
  Commit => plain text => byte[]
  Commit => Json => byte[]
  Commit => Json => Zip => Crypt =>  byte[]

We could add as a contrib project a simple denormalizer to write recombined streams (read model for the consumers)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants