Introduction to MongoDB

Schema Solution

Scott Moss

Scott Moss

Superfilter AI
Introduction to MongoDB

Check out a free preview of the full Introduction to MongoDB course

The "Schema Solution" Lesson is part of the full, Introduction to MongoDB course featured in this preview video. Here's what you'd learn in this lesson:

Scott live codes the solution to schema portion of the exercise.


Transcript from the "Schema Solution" Lesson

>> Scott Moss: Hope everyone had some fun and enough time to get some of those tests, if not all of those tests to pass. So I'm just gonna walk through all those solutions. And also you can check out to the master branch or the solution branch and see the solutions yourself.

But I'm gonna walk through the same solutions that are gonna be on that branch right now. So the first thing that we're supposed to do after we install and do all that stuff is create connection logic. And this logic is very important because the test itself actually uses this logic.

So it's basically gonna be exactly the same thing that I showed you all in the demonstration. It's just gonna use the mogoose.connect and then you pass the url. That's it. And once that's there, you're connected. Like I said, there are some other options you can pass here depending on what version you have.

Like for me, I might put use new url parser true or something like that to get the deprecation warrant to go away. But it's not that important right now. It still connects. So once you add that url, like I said this is very important because the testing setup that I'm using is using your connection logic.

So if this logic isn't working, then none of the tests will execute properly. So you would have had to have done this one first, which is why I put it first in the checklist. So once that's good, then let's head over to the user spec since Connor relies on user to be done.

And I'll just open these up side-by-side so we can figure out what's going on. So user spec, and then userjs. All right, so the first test, let's get this to pass. It says first name must be required. So we'll head over to the user schema and to the first name declaration field here, and we'll just put required true.

So we'll run that, and then we'll run our test.
>> Scott Moss: Get that command, I'm just gonna do a --watch. If you do --watch in JS, it will just keep the tests there and run them every time you change a file, so it doesn't have to rebuild every time.

So it looks like that one passed. I got one that passed, and just to verify if it was that one, we'll scroll up and it was. First name must be required. So that one's good. The next one says, last name must be required. Very much the same thing.

Just copy and past that required field down, and we're good. Test is re-running, looks like two pass now. And just to verify, last name must be required, so that one's good, okay? Keep going and if you want, just a quick tip with jes. You might see something that says expect.insertions1.

This is because if your code didn't throw an error I wouldn't know. So I have to tell jes that you should expect at least one insertion. Because if this code didn't throw an error, this catch would never run. And therefore, there would be no expectations. And then we would never if your test or failed.

We just wouldn't know. So this is captioning a failure that should be a failure, so that's why I'm telling you to do that. So for email, email must be required very much the same thing so I'm just gonna paste that required true in the email. And it looks like three is passing now, so if we verify that, we have,

>> Scott Moss: Email must be required so that passes. So, that's good. And then this is where it starts to get tricky. So email must be unique, okay. So we talked about this one a little bit, and it's just adding the unique field here to true. This is one way to do it, we will talk about other ways to do it when we talk about indexes.

Remember unique is not a validation it is an index. If you don't know what index is that's fine we are going to talk about indexes later. But it is an index, it is not a validation, completely different thing. So unique true is going to add an index here and in a test you'll see me doing something like user.init.

This is because indexes take time to build. And I need them to be built before I can actually use them, so user.init is telling mongoose, hey I'm just going to wait until you tell me when the index for the user is done because indexes have to be built.

They are basically Data in a file, and that file has to be written. And I need it to be there so I can check for validations against that index. So wait for the indexes to be built, and then try to create two users with the same email, and we'll see what happens.

So it looks like four tests are passing, before I go verify that. Email must be unique. So that one is good, good to go there. What else do we have in here? We have betaUser should default to false. So we didn't talk about defaults, but it looks like people were getting this one to pass because it's so intuitive, right?

It's probably what you think it is. Like what if I just add a default here to false? If you did that then you'd be right because that's exactly what it is. If you add a default field here. And you can put whatever value you want, as long as the value's the same type as the type.

So if we go look, we get 60 pounds here and that right there fixed the other test which needed other fields, too. So pass two tests just with that one fix.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now