Porting MVC Music Store to RavenStoreManagerController, 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:
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:
- (31 May 2010) StoreManagerController, part 2
- (29 May 2010) StoreManagerController
- (28 May 2010) Porting the checkout process
- (25 May 2010) StoreController
- (24 May 2010) Advanced Migrations
- (23 May 2010) Migrations
- (22 May 2010) Porting the HomeController, the Right Way
- (21 May 2010) Porting the HomeController, the map/reduce way
- (20 May 2010) Data migration
- (19 May 2010) Setting up the application
- (18 May 2010) The data model
Comments
Can you provide an example of the kind of code you would use to propagate a change to an artist across all albums?
Jay,
It is in a post coming up soon.
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?
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.
Ayende,
Thanks for the answer, that makes sense :)
Comment preview