http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Greg, Agreed. Version numbering with Raven is a bit interesting, basically you need a separate document to do the versioning, but it is pretty easy all around. http://ayende.com/4530/raven-event-sourcing#comment22http://ayende.com/4530/raven-event-sourcing#comment22Wed, 16 Jun 2010 06:14:41 GMTto be clear the problem is actually shown in your sample events. you have two with the same timestamp (create/add) and providing deterministic ordering in such a case is problematic. http://ayende.com/4530/raven-event-sourcing#comment21http://ayende.com/4530/raven-event-sourcing#comment21Mon, 14 Jun 2010 22:09:05 GMTOren, Looks good but generally I would run far far away from using TimeStamps to order and would instead use version numbers. Cheers, Greg http://ayende.com/4530/raven-event-sourcing#comment20http://ayende.com/4530/raven-event-sourcing#comment20Mon, 14 Jun 2010 21:08:43 GMTDemis Versioning is actually pretty easy, you just maintain the old index and deploy a new dll with the new index under a different name. The code needs to be written to be able to handle all users, but in practice, what we are doing is only re-executing the documents for the current user, not for all users. The reason that the code is written this way is that wew want to allow ourselves the option to do major optimizations down the road, where we can just shove data through this without having to do sorting up front. http://ayende.com/4530/raven-event-sourcing#comment19http://ayende.com/4530/raven-event-sourcing#comment19Sun, 30 May 2010 19:54:46 GMTThat's a pretty sweet and elegant example, hard to get it done with any less effort. Though I'm not sure about modifying the Raven Process with custom application logic .dll's - seems like a pretty fragile/state-full approach that would cause some pain during deployment, versioning, backing up, upgrading etc. Just trying to work out how efficient this solution is since I can't see the optimal code-path, i.e. when a user adds an Item to an existing cart does it rebuild the entire aggregate for all users shopping carts or just the one modified? or is that what the 'GroupByExtraction' lambda is for? http://ayende.com/4530/raven-event-sourcing#comment18http://ayende.com/4530/raven-event-sourcing#comment18Sun, 30 May 2010 19:47:34 GMTTobi, Take a look at my other posts on the subject. Look at the NoSQL category http://ayende.com/4530/raven-event-sourcing#comment17http://ayende.com/4530/raven-event-sourcing#comment17Sun, 30 May 2010 18:42:41 GMTOk, I get it for event processing, but I am more interested in the day to day work of users, orders, products... Some of us still have to get their hand dirty with boring stuff to pay the rent ;-) http://ayende.com/4530/raven-event-sourcing#comment16http://ayende.com/4530/raven-event-sourcing#comment16Sun, 30 May 2010 18:36:14 GMTTobi, Try writing something like this on a relational backend. The performance difference would be pretty big. Moreover, the amount of effort that you'll have to go through to get things done is extremely non trivial. Then try to add three new events, and see what happens. http://ayende.com/4530/raven-event-sourcing#comment15http://ayende.com/4530/raven-event-sourcing#comment15Sun, 30 May 2010 18:11:41 GMTAnd I want to add that this series is really starting to get my attention! This project is certainly having a pragmatic lead. http://ayende.com/4530/raven-event-sourcing#comment14http://ayende.com/4530/raven-event-sourcing#comment14Sun, 30 May 2010 18:10:03 GMTCould you comment a bit more on why you prefer using raven in a document oriented way instead of in a relational way? It seems to me that it would result in less code if you were to keep everything normalized and dry. I know that performance might not be that good but disregarding that I think it would be a superior approach. You would just define indexes for all access path' to the data that you have so it still would be lightning fast. (you might notice that development speed is my major concern because I do not develop apps with huge data sizes. This is certainly a common scenario that might justify a dedicated post... ;-) ). http://ayende.com/4530/raven-event-sourcing#comment13http://ayende.com/4530/raven-event-sourcing#comment13Sun, 30 May 2010 18:08:45 GMTThomas, This runs in Raven's process. Yes, Raven has a plugin mechanism, drop a dll to Plugins/, and everything works. Defining indexes via the web interface: [www.ravendb.net/documentation/docs-http-indexes](http://www.ravendb.net/documentation/docs-http-indexes)http://ayende.com/4530/raven-event-sourcing#comment12http://ayende.com/4530/raven-event-sourcing#comment12Sun, 30 May 2010 17:29:19 GMTTobi, Yes, the index update on every new commit, and it is updated in an efficient incremental manner. In your case, it would only update the current day. http://ayende.com/4530/raven-event-sourcing#comment11http://ayende.com/4530/raven-event-sourcing#comment11Sun, 30 May 2010 17:27:58 GMTYes, this code is beautiful, really beautiful. And my sql oriented brain almost blew up when I tried to understand the process. http://ayende.com/4530/raven-event-sourcing#comment10http://ayende.com/4530/raven-event-sourcing#comment10Sun, 30 May 2010 16:38:05 GMTBeautiful. http://ayende.com/4530/raven-event-sourcing#comment9http://ayende.com/4530/raven-event-sourcing#comment9Sun, 30 May 2010 15:15:38 GMTIn which process does this view-generator run? Since raven needs to keep the index up to date, I'm assuming it has to run in raven's process? If so, do you have something like a plugin/extension system where you drop some dll somewhere or how does it work? How would you define this index using ravens webinterface? I have to add, that I never tried raven or looked at the code and so I don't have a lot of knowledge of its internal structures besides the post of yours. I'm just curious ;-) http://ayende.com/4530/raven-event-sourcing#comment8http://ayende.com/4530/raven-event-sourcing#comment8Sun, 30 May 2010 14:54:04 GMTI'd be interested in what amount of information in the materialized view/index will be recalculated if the underlying "table" changes. Say, we were to use raven for logging all of our http requests and we had an index "count of requests per day". Would the index be updated incrementally? http://ayende.com/4530/raven-event-sourcing#comment7http://ayende.com/4530/raven-event-sourcing#comment7Sun, 30 May 2010 13:19:16 GMTUriel, It isn't, really. It is just a different way to build the index, that is all. http://ayende.com/4530/raven-event-sourcing#comment6http://ayende.com/4530/raven-event-sourcing#comment6Sun, 30 May 2010 12:33:27 GMTSo what is the difference between this and a regular raven index? http://ayende.com/4530/raven-event-sourcing#comment5http://ayende.com/4530/raven-event-sourcing#comment5Sun, 30 May 2010 11:13:06 GMTMarkus, Yeah, pretty much. There is a much more extensive example that does it in a manner that is much nicer that is currently working up. This is just to show how things are working http://ayende.com/4530/raven-event-sourcing#comment4http://ayende.com/4530/raven-event-sourcing#comment4Sun, 30 May 2010 11:03:37 GMTUriel, All of Raven's indexes are similar to materialized views http://ayende.com/4530/raven-event-sourcing#comment3http://ayende.com/4530/raven-event-sourcing#comment3Sun, 30 May 2010 11:02:23 GMTThis is really cool and tips my balances in favor of RavenDB against NH again. I have one remark though: You should mention that you violate OCP voluntarily to keep the code simple and that in production the switch statement should be replaced by an extensible approach, i.e visitor or strategy patterns. http://ayende.com/4530/raven-event-sourcing#comment2http://ayende.com/4530/raven-event-sourcing#comment2Sun, 30 May 2010 10:37:30 GMTthis is something like couchdb materialized views? http://ayende.com/4530/raven-event-sourcing#comment1http://ayende.com/4530/raven-event-sourcing#comment1Sun, 30 May 2010 09:37:12 GMT