Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
SQLStreamStore vs NEventStore vs EventStore #108
Your project is relatively new and exist in the same area as more mature Event Store and NEventStore (and a few others).
Can you explain the reasons, why this project was created? What are the benefits ( and disadvantages) to use your library? Why I (as new in Event Store area) should choose your library?
It will be good to add the answer to wiki.
Good Q. Was meaning to blog about this, but here will do.
That's it really. Hope it helps. Closing but follow up with any further questions if needed.
edit: fixed some typos
I randomly stumbled across this and appreciate the pragmatism.. and I am asking without ever using SSS.
It seems they had to formally add the notion of a commit to make up for the lack of multi-doc atomicity in Mongo. I presume SSS supports atomic multi-event writes? If so, is the issue that in NES a commit is public API vs a transparent wrapper to make up for the lack of atomicity in Mongo?
So SSS puts the emphasis on simple data structures rather than types? Could you elaborate on this a bit more?
@bruth apologies for late reply (I get many messages and this fell through the cracks)
I didn't design NES but yes, that is an issue for me. It also makes walking streams (forwards, backwards, from arbitrary version / position) very complicated and sub-optimal perf wise.
Point 10 addresses this I believe. Is there something more to expand on?