Is Raven enough to implement an event store?
Georgios Diamantopoulos
Here are my implementation thoughts:
- Store events using semantic ids for each aggregate root
- use a view generator if rebuilding an object from the events is required as per Oren's blog post
- use the changes api to be notified of new events (how to avoid duplicae handlings on a web farm?)
Am i on the right track here? Missing anything?
Thanks
Georgios
Kijana Woodard
I've been having these same thoughts but haven't had time to delve deeper. Interested in responses.
My thought on changes is that you wouldn't subscribe to changes in a web farm because they are inherently unstable. You would subscribe within a stable process and either write new docs, publish events on a bus, notify via signalr, etc, etc.
Carlos Mendes
Kijana Woodard
Yes. For me more curiosity than practicality.
Kijana Woodard
I think the OP is interested in the doing es without the joliver project to see if he really needs the latter.
Matt Johnson
Ritchie's "NES" project https://github.com/elliotritchie/NES
I ended up ditching it. The biggest drawback was the difficulty to
query into the data. I had to keep a separate event store AND a
flattened view of it in normal documents. I was doing twice the work
to get very little gain. While there's nothing wrong with event
sourcing, and joliver and eritchie have done a great job, the reason
it can use just about any persistence is because it takes very little
advantage of anything the persistence engine might have to offer. You
might as well use sql server or flat files for that matter.
If I were to consider event sourcing again, I would want something
that made it easy for me to query against and take full advantage of
full text search, map reduce, etc.
On Dec 21, 7:56 pm, Kijana Woodard <kijana.wood...@gmail.com> wrote:
> I think the OP is interested in the doing es without the joliver project to
> see if he really needs the latter.
>
>
>
>
>
>
>
> > Yes. For me more curiosity than practicality.
Kijana Woodard
So that's part of my musings, to have that single repo.
The flutterings in my mind indicate that it would work as a rough inverse of your temporal versioning bundle.
You start with the events and define a class/script that builds a document. So given that class you can always see what the document looked like at a given event/time in the stream. Plus you get to define several documents from the same set of events.
Normally, you have to break documents down to reshape them. This is just building docs up.
It's all still very loose in my head, but it all seems attainable. Oren has a post on event sourcing which demonstrates an es index.
Having that all queryable would be............nice, to say the least. Adding in the changes api to inform collaborators is icing.
Matt Johnson
You might use temporal versioning to persist the effects of the event stream so you could do more with the resulting data, but the event stream itself would probably be separate.
BTW - I'm almost done with some major improvements to temporal versioning that will make it a LOT easier to use. Will post when ready.
From: Kijana Woodard
Sent: 12/21/2012 9:02 PM
To: rav...@googlegroups.com
Subject: Re: [RavenDB] Re: Is Raven enough to implement an event store?
Kijana Woodard
Right, not a corollary. I see it as roughly the opposite. Given doc versioning, I can get diffs and can construct events - who/what/when. Conversely, given events, I can construct temporal docs. What was the state at this point in the stream of events/point in time.