Generate new event id rather than deriving it

[tpaulshippy]

When writing event documents to the underlying store, the ID should be a consistent known format, rather than derived from the commit id plus the commit sequence. From a data store perspectives, if someone is using UUIDs, they expect UUIDs everywhere. Or if it's mongo ObjectIds, they should be consistent. I don't see any other code that assumes that the event id is derived. Of course if consumers are making this assumption, this would be a breaking change.

[nanov]

This is the ID in the event store, if you inspect the documents closely you'll see that inside payload there is another id ( generated by the domain ).

As for your PR, getNewId might by asynchronous ( in other implementations like redis, or even here ), your logic will result events with id undefined in this case.

[nanov]

Just to be clear, I am open to discussions as of better way to store the events, assure order and consistency.

One of my ideas is implementing a "commit" store, rather than an event store, this means that each document can contain multiple events. This way one could assure atomicity, and queries could be mongo aggregates in order to achieve event-series.

Another idea that i have is to store the id of the previous commit ( or event ) with each one ( not unlike git ), this way denormalising events, and catching missing ones would be a breeze.

All those, will be probably better done as a major version release, dropping some old node versions ( < 8 ) support and introducing new APIs.

[tpaulshippy]

I understand that that ID is just for the event record itself, and that it is not the ID that generally should be referenced. But my team is loath to have a derived ID for any document in our mongo database. The primary reason is that if we were to migrate our data to a different data store, we should have the option of using a consistent data type for the IDs. For example, SQL Server has a uniqueidentifier data type that would work for UUIDs but would not work for a UUID + integer.

Good point on the asynchronous possibility. I will submit a new PR, since this one got cluttered with that mongo method stuff also.

Interesting thoughts on a commit store. I could see that being good. I definitely like your thought about storing the ID of the previous commit. If you are going to go that direction at some point, I'd suggest going ahead and using one-way hashes derived from the content so that you can guarantee immutability (a la blockchain).