Noob Issue about default event metadata & serializer settings

EventStoreDB
1

I’ve started to play around with EventStore and was leveraging the CommonDomain stuff as a start. I am using NancyFx as a thin “web api” layer.

I have an an Employee aggregate storing an id, personal info (name, gender, etc.), contact information (email addresses, etc.) and family information. When a post is made to domain/Employees, I build a CreateEmployee command which is turned in to 4 events… EmployeeCreated (establishes the unique id); PersonalDetailsReplaced (replaces name, birth date, gender, etc.); ContactInfoReplaced (replaces email addresses, etc.); FamilyInfoReplaced (yep, replaces family data).

When I try to Save all four [uncommitted] events, I get some weird results. Since only four events, I am using the AppendToStreamAsync method.

  1. Creating the metadata with a commitId (Guid), aggregateClrTypeName and eventClrTypeName doesn’t seem to work. Seems like the server overwrites and creates its own commitId and type name information. Is this expected? Any pointers on how/where I would change the behavior? When creating the EventData to send to AppendToStreamAsync, should the serialized metadata byte field only contain information above and beyond these three fields?

  2. When saving the first aggregate, the commitId is always zeros (a guid consisting of all zeros) which shouldn’t be the case

  3. When saving the second aggregate (different data), the serializer seems to change and now includes TypeHandlingInfo?! So, the metadata has a $type of IDictionary<string,object>… why did the serializer settings change as the program is running?

  4. When saving the third and fourth aggregates (replaying the previous two post commands), the save appears to work as expected – a proper commitId (but not set by me) and the type information for the aggregate and event (also not set by me)… in fact when I create EventData now, I pass null for the metadata byte array (cause I wanted to make sure I wasn’t setting the metadata).

Why does it take until the 3rd write attempt to get it right? Have I configured something in correctly?

I am using EventStore server 3.0.1 and ClientAPI 3.0.1.

Thanks for your time and help.

Rob

2

We don't deal with any of the stuff you are talking about. This sounds
like issues in CommonDomain.

For us EventData and EventMetadata are just vectors of bytes. We take
them and hand them back.

For commit ids we don't have any concept as "commit id' in our system.
For eventType there is an eventType but its a string.

My guess is the best way of debugging would be to look at what you
actually write into EventData and what you get back from EventData on
your read.

Greg

1) Creating the metadata with a commitId (Guid), aggregateClrTypeName
and eventClrTypeName doesn't seem to work. Seems like the server
overwrites and creates its own commitId and type name information. Is
this expected? Any pointers on how/where I would change the behavior?
When creating the EventData to send to AppendToStreamAsync, should the
serialized metadata byte field only contain information above and
beyond these three fields?

2) When saving the first aggregate, the commitId is always zeros (a
guid consisting of all zeros) which shouldn't be the case

3) When saving the second aggregate (different data), the serializer
seems to change and now includes TypeHandlingInfo?! So, the metadata
has a $type of IDictionary<string,object>... why did the serializer
settings change as the program is running?

4) When saving the third and fourth aggregates (replaying the previous
two post commands), the save appears to work as expected -- a proper
commitId (but not set by me) and the type information for the
aggregate and event (also not set by me)... in fact when I create
EventData now, I pass null for the metadata byte array (cause I wanted
to make sure I wasn't setting the metadata).

3

Thanks… your kick in the arse got me to looking at it closer. Since I knew there was only one place where I create EventData and I set the data and metadata to null … I couldn’t explain why the web UI was showing data for both… until I looked closer and realized it was a browser cache issue. Yep, I feel pretty dumb.

In any case, thanks for your help/kick and super fast reply.

Rob

4

OK cool! Let us know if you have any issues.

Cheers,

Greg