This code ain’t production ready
Greg Young has a comment on my Rhino Events post that deserves to be read in full. Go ahead, read it, I’ll wait.
Since you didn’t, I’ll summarize. Greg points out numerous faults and issues that aren’t handled or could be handled better in the code.
That is excellent, from my point of view, if only because it gives me more stuff to think about for the next time.
But the most important thing to note here is that Greg is absolutely correct about something:
I have always said an event store is a fun project because you can go anywhere from an afternoon to years on an implementation.
Rhino Events is a fun project, and I’ve learned some stuff there that I’ll likely use again letter on. But above everything else, this is not production worthy code .It is just some fun code that I liked. You may take and do whatever you like with it, but mostly I was concerned with finding the right ways to actually get things done, and not considering all of the issues that might arise in a real production environment.
Comments
But your code is worth for others to learn the Events store . The concept of event store and how to build it and use it was never clear for me. So its fun project as well it helps people to learn things.
@satish have you looked at event store code on github? it is bsd license. Every issue I mentioned is handled in at minimum some way.
@oren I'm always happy to discuss such issues because they are fun. To be honest even though we handle all these we could go much much deeper. The guys working on oracle or SQL server have been for a decade or two with a much harder problem. There is so much to learn.
For me what would be really interesting as a goal is to say raven will take over its own transactions. Easy to say hard to bring to production. How can we help?
Greg, The problem with saying that Raven will implement its own transactions is that we use Esent. And that storage has been around for decades. All those issues that we were talking about, and probably a lot more, are already handled there. It is hard to justify recreating all of that.
@Greg young
A bit off topic for this post, but I'm struggling to understand why I might want to use an event store. If I understand correctly, it's basically all about pub/sub queues - so why wouldn't I use a durable message queue like RabbitMQ?
Maybe it's a lame question but I have to ask it: Why Rhino.Events was created? What is the reason for its existence, what problem does it solve and how? And are there any similar tools for comparison?
Rafal, It was created because I had an itch.
@cocowalla there is a 6.5 hour video on dddcqrs.com that explains how people use them. It is not just a message queue.
@Greg young
Anything more concise than 6.5 hours available? :)
Comment preview