Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Porting MVC Music Store to RavenStoreManagerController, part 2

time to read 3 min | 409 words

There are two methods in StoreManagerController that we haven’t touched yet. Dealing with them is going to just a little bit different:


Can you figure out why?

The answer is that when we started, we decided that there really isn’t any reason to store artists as individual documents. They are just reference data, after all. Now, however, we need to reference them.

We could, of course, create a set of artists documents, at which point it would be very easy to port the code:


But I still think that artists don’t really exists in this model as an independent entity. So instead of going with this route, we are going to project them.

We define the “Arists” index using the following map/reduce linq queries:

// map 
from album in docs.Albums
select new { album.Artist.Id, album.Artist.Name }

// reduce 
from artist in results
group artist by new { artist.Id, artist.Name } into g
select new { g.Key.Id, g.Key.Name }

If you’ll look carefully, you’ll notice that this is essentially doing a distinct over all the artists across all albums.

And that means that we can now write the code for those two methods like this;


There is one very important things to remember here: In Raven’s queries are cheap, because Raven allows you to query indexes only, and those indexes are built in the background, making queries tend to be very fast.

That changes the way that you think about designing you system and data model. You want to move a lot of your processing to indexes and queries upon those indexes, because it tends to be cheaper all around.

More posts in "Porting MVC Music Store to Raven" series:

  1. (31 May 2010) StoreManagerController, part 2
  2. (29 May 2010) StoreManagerController
  3. (28 May 2010) Porting the checkout process
  4. (25 May 2010) StoreController
  5. (24 May 2010) Advanced Migrations
  6. (23 May 2010) Migrations
  7. (22 May 2010) Porting the HomeController, the Right Way
  8. (21 May 2010) Porting the HomeController, the map/reduce way
  9. (20 May 2010) Data migration
  10. (19 May 2010) Setting up the application
  11. (18 May 2010) The data model



Can you provide an example of the kind of code you would use to propagate a change to an artist across all albums?

Ayende Rahien


It is in a post coming up soon.



I suppose having an index on artists only having albums serves only to give an example, but in that case why have an Id per artist? Wouldn't it be easier just to save the name?

And if the Id just guarantees data integrity, what would be the best way to save both properties? Is it loading the Artist or Genre just before Creating/Editing the Album since connecting to the db is not too expensive?

Are you intending to have at some point the possibility to pass only the Id to the Genre or Artist property and Raven will do the rest, that is populate the other properties (in this case the Name), the way it works in NH? Or am I missing the whole point?

Ayende Rahien


Because presumably the artist information comes from a source that have the id, and I don't want to lose that.

Artist may also have the same name, so I use the id to distinguish them.

And data integrity, in the sense that you use that term in relational databases isn't that meaningful in a NoSQL store, because that is a different world.

And no, you can't do the NH trick with Raven, because Raven explicitly doesn't do relations.



Thanks for the answer, that makes sense :)

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats