In this video we're going to write out an implementation for our order model.
We're going to write out some description of the order model using some Mongoose related code.
Let's get to it right away back inside of my editor.
I want to very quickly give you just a very fast reminder.
We've been over this twice downside of course.
If you go back to our OTT service and find the models directory and then user t inside there.
So remember whenever we're getting a mongoose and type script to work together a good way of doing this
is to write out those three interfaces at the top of the file.
One describes the properties that are used to create a user or create a record.
We've got another interface that describes all the properties that a saved document has and then a third
interface to describe all the properties that the overall model has.
Remember the model represents the overall collection we build that interface to Scott the model to specifically
add in that one extra method right there at the build method the whole reason that we're putting to
that build method is just to allow typescript to do some validation or type checking of the arguments
or are using to create a new document so that we got that reminder out of the way back to our order
service inside of our SRT directory.
We'll make a new folder called models and then inside there a new file called order that T.S. at the
very top let's get mongers will then create those three interfaces we don't need to enter or export
that my mistake.
So interface order matters interface order duck extending Mongoose stop document
and then order model extending Mongoose dot model.
And this is a generic type.
So we will put in order duck like so let's down provide some types for each these different interfaces.
First off.
Order adders.
So this thing is going to have a user I.D. That is a string a status for the order which is give me
a string as well.
We're going to come back and update the type on string and just a little bit.
But right now we'll just leave it as a string then expires at.
Which will be a data object and then finally and this one is going to add a little bit surprising because
back on this diagram over here I said that in order was going to have a ticket I.D. and so that implies
that well we're going to have a ticket I.D. that has a string or something like that.
But remember in the last video we just discussed that to actually relate an order with a ticket.
We're going to somehow embed a reference over to a ticket document.
So to do so and we'll go further into this feature in just a little bit we're going to say that order
adders has to have a ticket property not ticket i.e. a ticket property that is an instance of a ticket.
So we're going to write in ticket doc right there.
We do not have a ticket Doc type inside of our orders service just yet.
So right now that's going to result in an error and we're not going to fix that for a little bit.
So we're going to leave that for right now.
We'll come back to it and discuss a bit more about what's going on with this ref population feature
in a moment.
Next up is order duck.
So order documents are going to have the exact same set of properties that are required to create an
order.
Remember the reason we create these two separate interfaces is because the properties that are required
to create an order might be different than the properties that actually end up on an order.
So that's why we've got these two separate interfaces.
This project here or this service right here is finding the first time where they are going to end up
with a different set of properties.
That's why we have the two separate ones.
But right now they are going to be temporarily identical.
So going to take all the properties off of order adders will be just added and paste them down into
order duck as well.
Then after that let's do our order model.
So all we're doing here is saying that a model has this one extra little method on it called built.
It's going to take an argument called adders that is of type order adders and out of that we will get
an order document.
So there's are three interfaces.
So now let's build out our schema that actually describes the different properties in some rules about
them that we're gonna have on an instance of in order to create order schema.
This will be a new Mongoose start schema on the first argument right here.
We'll have an object where we'll provide these different properties.
So we want Mongoose to worry about on in order.
So first off there's going to be a user I.D. its type is going to be string.
Remember the type right here of string.
This is actual kind of javascript code that really gets executed whereas the interfaces up here are
typescript interfaces that get stripped out before our code is executed.
The types we're listing right here are typescript types.
So this is a lowercase string whereas down here this is an actual value that will be consumed by mongoose.
This right here has a capital S string as that is the string constructor we definitely want to make
sure that every order that gets created has a user tied to it.
So put on a required true property next up we're gonna say that every order has a status it's going
to be of type String and that will also be required.
So every order that gets created at all points in time it must have a status to describe if it is awaiting
payment if it's been canceled if it's been purchased and so on.
Next up expires at.
So this will be of type Mongoose dot schema dot types dot dates.
That's how we say to Mongoose that something is going to be a date property or a date.
Object.
Now this one is not going to you will be required because there might be scenarios where we do not actually
want in order to ever expire.
For example after a ticket has actually been or an order has actually been paid for it's own pace for
an order we no longer want to expire it so we might eventually set expires out to be null or undefined
or something like that.
And then finally here's where we're going to set up our actual reference between the order document
and a ticket.
So we're gonna say that there is a ticket property its type is going to be a mongoose schema types object
I.D. and then we're going to put on here as well ref of ticket.
So again in a time back into this whole reference system that we just discussed in the last video we're
going to get a deeper dive on that whole system in just a moment.
All right.
So there is our Mongoose schema or least the first argument we're not going to put in the options argument.
So a second argument to this thing that is also give you an object inside of here we're going to set
that to Jason property we'll define a transform function and remember the whole goal the thing is to
take in some value that we're trying to turn into Jason.
We're gonna delete off that underscore I.D. property and set it on the I.D. property instead.
So we'll say red dot I.D. is red dot underscore I.D. then delete red underscore i.e.
get just a little bit more after all the schema stuff will then define the build method on the order
schema statics object.
So this is what is going to give us the build method on the actual order model so just like we've done
on our other services we'll say order schema statics dot build.
This is going to be a function that takes in some argument of adders and it must be of type order adders.
Now we're going to return a new order and throw the attributes inside there we can air out of order
right here but that will go away in just a moment right after we say const order is our actual Mongoose
model remember model is a generic function so going to put on those angular brackets and then through
in order duck ordered model then the name of the collection which is going to be order and then our
order schema then finally at the very bottom export order in curly braces OK so that's it now at this
point there's really two big points of discussion or two things we need to kind of figure out we need
to understand a little bit more about how that ref system with Mongoose works because what is this type
right here exactly why is the type object I.D. as opposed to say type ticket or something like that
we've got to figure out a little bit more on that side we need to make sure that we define these ticket
Doc interfaces somewhere inside of a project and then also I mentioned that we're going to give a better
type 2 status right here to describe the status of an order.
So we gotta figure that out as well.
So just a little bit work left.
Let's take a pause right here and tackle these problems in just a moment.