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: 5,972 | Comments: 44,525

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

No future posts left, oh my!

RECENT SERIES

  1. Production postmortem (5):
    29 Jul 2015 - The evil licensing code
  2. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats