Ayende @ Rahien

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

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 18 | Comments: 86

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:

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.

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

Comments

Jay
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

Jay,

It is in a post coming up soon.

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

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

Ayende,

Thanks for the answer, that makes sense :)

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Buffer allocation strategies: A possible solution - 3 days from now
  2. Buffer allocation strategies: Explaining the solution - 4 days from now
  3. Buffer allocation strategies: Bad usage patterns - 5 days from now
  4. The useless text book algorithms - 6 days from now
  5. Find the bug: The concurrent memory buster - 7 days from now

There are posts all the way to Sep 11, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    03 Sep 2015 - The industry at large
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats