search

NEventStore / Discussions

Talking about NES & vNext
0 stars 0 forks source link

Persistence of events as byte array #3

Open alkampfergit opened 9 years ago

alkampfergit commented 9 years ago

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 commented 9 years ago
alkampfergit commented 9 years ago

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 commented 9 years ago

+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 https://github.com/NEventStore/Discussions/issues/3#issuecomment-109193978 .

Mauro Servienti Microsoft MVP - Visual C#

andreabalducci commented 9 years ago

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)