Ayende @ Rahien

Refunds available at head office

Porting MVC Music Store to Raven: StoreManagerController, part 2

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

image

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:

image

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;

image

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.

Tags:

Posted By: Ayende Rahien

Published at

Originally posted at

Comments

Jay
06/01/2010 01:19 PM by
Jay

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
06/01/2010 07:47 PM by
Ayende Rahien

Jay,

It is in a post coming up soon.

Nieve
07/18/2010 06:13 PM by
Nieve

Ayende,

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
07/22/2010 08:00 AM by
Ayende Rahien

Nieve,

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.

Nieve
07/22/2010 08:14 AM by
Nieve

Ayende,

Thanks for the answer, that makes sense :)

Comments have been closed on this topic.