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

IDocumentSerializer and its usage is flawed #42

Open
AGiorgetti opened this issue Aug 3, 2016 · 1 comment
Open

IDocumentSerializer and its usage is flawed #42

AGiorgetti opened this issue Aug 3, 2016 · 1 comment

Comments

@AGiorgetti
Copy link
Member

There's a problem in how the thing is used to implement custom serialization of the events in a commit which impacts the database schema that is generated.

This interface is also used in different ways in each driver implementation and this should be documented

The original implementation did:

new BsonDocumentWrapper(typeof (EventMessage), serializer.Serialize(e))

which implied that the output of a serializer.Serialize method should have been something derived from EventMessage, but this wasn't evident from the documentation.

The actual implementation on develop does:

new BsonDocumentWrapper(serializer.Serialize(e))

there's no more nominal type usage anymore, so there's no more implicit inheritance of the object that will be serialized inside the payload, this will cause schema differences, because mongodb c# driver is now adding a "_t" attribute to each serialized object.

We should define correct usage of this interface, which IMO should be (to keep compatibility with the past):

  • in the serialize stage: output an EventMessage class (which sould be sealed in NEventStore) doing you custom serialization in the body property og the EventMessage itself.
  • in the deserialization stage: the input will be an EventMessage with a serialized body, decode it and produce another EventMessage with a deserialized output.

otherwise we can go for having a 'private' EventMessage-like class in the driver that we'll use to keep schema compatibility.

@AGiorgetti
Copy link
Member Author

In the meanwhile I think the right thing to do is to revert to the original way of serializing an EventMessage using the explicit nominal type.

@AGiorgetti AGiorgetti added the bug label Aug 3, 2016
AGiorgetti added a commit that referenced this issue Aug 3, 2016
due to Issue: #42 it's probably better at this tage to keep the
compatibility with the past regarding how the events are serialized in a
commit. We should rethink the whole usage of IDocumentSerializer.
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

1 participant