This course has been updated! We now recommend you take the API Design in Node.js, v4 course.

Check out a free preview of the full REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course:
The "Solution: MongoDB Models" Lesson is part of the full, REST & GraphQL API Design in Node.js, v2 (using Express & MongoDB) course featured in this preview video. Here's what you'd learn in this lesson:

Scott walks through building out the model schemas in Mongoose.

Get Unlimited Access Now

Transcript from the "Solution: MongoDB Models" Lesson

[00:00:00]
>> Scott Moss: All right, so hope this challenge was fun for everybody with the test and all and it wasn't too difficult and everybody was able to get through it. If not, we're gonna do that just now. So if you, let me check out, to my solution this should be lesson five.

[00:00:18] Lesson five, I don't want to put these changes in there. There we go. So if we run the test on lesson five, solution or if you've not checked out the solution, then I am. What's failing? I got the queries enabled, just ignore my query test. But all the model specs are passing, so we can go take a look at that and see how we can satisfy those models.

[00:00:51] Let's start with the playlist model. So if we go there, playlist.spec. Over there, .model over here. Close that, okay. So for the playlist model, if we look at the test it says it should have a title, that's misspelled, tilted. Should have a title to exist, should have a type that's equal to string and it should have a required property that's an array.

[00:01:25] So, if we go look. Here we go. Type of string. Requires an array, true and then playlists must have titles is a custom error, okay. If we look at this next one, should have songs, should exist, which it does. Should be in an array, which it is. And then song0.type.

[00:01:43] So, right there, that's telling you that the first thing in the array is probably an object with a type property. And if you did some more deduction, you would realize, like it's just the same thing as this. It's got a type property. Type is a key word in Mongoose.

[00:01:56] In fact, if you needed a property called type, and you want it to be string, you couldn't do that. You'd have to say type, type:string in order to get around that. You can also tell Mongoose what's typekey. I think it's typekey, you can get a different key if you want.

[00:02:15] So it's not type, it would be something else. By default it's type. Small tip. So, expects the first thing in there to be an object, who's type equals mongoose.Schema.Types.ObjectID, and who's reference is a song. This is setting up an association that we can later populate, all right? Okay, and then, it says, it expects favorite to exist, expects it to be a type boolean, expects it to be required and expects the default to equal false.

[00:02:51] Everybody got that? Looks very similar to that. Okay, so now we can look at the song spec
>> Scott Moss: And I'll go over there.
>> Scott Moss: So, the song line, it should also have a tilte [LAUGH], a title and expect it to exist, expect the required to be an array, which it is, URL, expected to exist, expected to be unique, expect the required to be an array.

[00:03:26] Album, expected to exist, rating, I'm sorry, artist and album expect to exist. I'm not even checking for types there. Rating expected to exist and then equal a number and then favorite's got all this other stuff on it. So let's check and see if it exist and if it's a boolean.

[00:03:42] Print out some stuff, and then if we look at the user line, which is the easiest of all. This one's just checking to see if it has a user name and this thing called password hash and it's just doing some validations on that right? So checking to see if the user name exists, if it's a string, if it's required and if it's unique and then hash if it exists, if it's a string, and if it's required.

[00:04:06] And if you run that you should get all your tests to pass. So everybody all their tests passing? Nice, so much easier when you can just get tests to pass like that's the best way. If somebody gets to come in, write all your tests for you and you just wrote the code to make that pass.

[00:04:22] How easy would your job be? Think about that. What if there was teams where this person writes tests, this person builds features, that's it. Right, that'd be ideal. I think people should write code like that. And then you switch it up so you're not doing one thing all the time.

[00:04:38] Maybe I'll try that. I'll try that and report back. [LAUGH]