In the last video we added on the recipient's schema to set up the sub document collection.
Now there's just one or two more properties that I want to add to the schema right here.
Just while we're looking at it the first one is going to be a very necessary piece of code in a very
necessary little addition to our schema.
Remember that we've been saying up to this point that a user will have many surveys and so we need to
somehow identify which survey belongs to which individual user.
So to set up a relationship between our survey and between our user We're going to add another property
to our survey schema object.
So I'm going to go back over to my code editor and then down here at the bottom I'm going to add on
one additional property I would call it underscore user then to make mongoose understand that this is
going to be a reference to a very particular user or to a another instance of a user to make mongoose
understand that we are setting up some type of relationship right here.
We're going to assign an object to this property we're going to give it a type of schema types object
id make sure that ID has a lowercase D and then we're going to give it also a ref property of user like
so OK.
So let's talk about this line right here a little bit with this property.
We add the idea to survey schema that every survey is going to belong to a very particular user.
First off indicate that it has a type of schema type object ID.
So whenever this record whenever a schema actually gets saved to our database if we look up this user
property we'll see an ID for assigned to this field right here and it will be the ID of the user who
owns this record.
Now notice we also add in reference here of user like so.
So this tells mongoose that the reference that we're making this too belongs to the user's collection.
Now the other thing I want to mention is that you'll notice that we prefixed this property name with
an underscore here that is not at all required.
So we could have just as easily called this thing user or it could have been owned by or it could have
been I belong to absolutely anything we want but by convention we might make use of underscore user
like this to make it obvious to anyone who's looking at this that this is supposed to be a relationship
field or it's supposed to set up a relationship between this model and then and another one.
So it's not necessarily some other silly property like all the other ones in here that contain raw data
the underscore indicates that hey this is a reference field.
OK.
So that is going to be used to set up a relationship between a given schema and a given user.
Now the very last two fields that I want to add in here and these are two fields that we haven't spoken
about previously but I want to put on just to give you a little bit of an example of how you might kind
of spice up the application a little bit.
We're going to add on to additional fields here.
The first one is going to be date scent of type date and then the next one will be last responded of
type date as well.
So the idea behind these as you might imagine any time we send out a survey via email will record the
date that it was sent.
We'll also make sure that we record the latest time that someone has voted on a given survey.
So between these two properties right here we'll have the ability to give our users the idea of whether
or not a survey is still kind of active.
So we will be able to tell them hey here's when you sent the survey out and you've gotten like 500 responses
in that time and the last time that someone responded was like a week ago.
And so the last time you got a response was one or two weeks ago chances are you might not be really
expecting to get a lot more feedback beyond that point.
So these two fields right here are definitely not at all necessary for making our application work.
There just a little bit of nicety to provide a little bit more feature to our users.
OK.
So we spent a lot of time on our survey schema and I think that it is now looking pretty good.
So we've got our pretty core properties right here.
We have embedded a list of recipients to make sure that we only ever let any given end user click on
an e-mail link.
One time we are recording the number of times someone votes or some of the total number of yeses and
nos.
We've got a relationship between the survey and a very particular user.
And then we've got two additional fields in here to just give ourselves a little bit more information
about this particular survey.
So I think this is looking pretty good.
I think that we are now ready to start putting together our endpoint to create and save a new schema.
So let's continue in the next section and start putting together our new API endpoint.