We are onto our very last test here.
So we need to make sure that if we send in some valid values and we are authenticated it ticket actually
gets created.
Once again let's write out the test for this first.
So I think that the general request itself is going to maybe look something like this.
Maybe something like a weight request to app.
We want to do a post to API tickets and I want to send along some valid title so some string and a valid
price of say 20 I'm going to say that if we successfully create a ticket I want to try to send back
a status code up to a one indicating that a record was created.
But by just asserting a two a one right here we're not actually checking to make sure that a ticket
was created and saved to the database or anything like that.
So I would really like if we could somehow write out some check inside of here to make sure that something
was saved to the database.
We don't really have anything inside of our tickets project just yet to work with the Mongo database
that we've allocated so far right now I'm going to put in some comments to remind myself again to say
add in a check to make sure a ticket was saved.
So we will come back here very shortly and add something else in OK.
So without a doubt the next you're going to have to work on to make sure that we can actually save a
record to the database then eventually fetch some data or make sure that thing was saved is a ticket
model.
So remember we work with our Mongo DB database using mongoose in order to have Mongoose communicate
with Mongo DV.
We have to create a model and that model represents the collection of records we have inside of Mongo
DB.
Reading a mongoose model with type scripts is a little bit confusing.
So let's go back over to our OTT service by the models directory and then the user test file inside
there and just get a quick reminder on how we build a mongoose model with typescript to back over here.
We had created those three interfaces at the very top.
We had an interface that described the properties that were required to create a record the user dock
right here.
I'm skipping over the middle one the duck described these properties that a saved record had and then
the model represented all the different properties that were going to be assigned to the model itself.
And remember the model essentially represents the entire collection of data.
The document represents one single record.
We then created our schema which lists out all the properties we wanted.
We also had a two Jason function side there.
Remember too Jason was going to somehow manipulate the Jason representation this data.
The most important thing we did inside of here beyond removing the password for our user in particular
remember Mongo saves I.D. to a record as underscore I.D. That is super atypical not very standard.
And so to make sure that we could have Mongo DB running as a back end database along with possibly other
databases in the future we wanted to make sure that all of our Jason representation these records always
presented the I.D. simply as I.D. as opposed to underscore I.D..
So we're going to need to make sure that we do this for the ticket model we create as well after that.
We then set up the pre safe hook that was only required because we were hashing a password.
So that will not be needed on our ticket model.
We then defined that build function.
Remember the entire goal of this build function was to just allow typescript to do some validation or
type checking on the properties we were trying to use to create a new record.
That was the only reason we made built whenever we tried to create a record directly by using that user
model.
There's not any type shaking that goes on with the attributes we pass in.
That's why we made this building after that.
We create the actual model and then export it.
We're going to do just about the exact same thing or a ticket model we're gonna write out the three
interfaces the schema the build method insulin so for the ticket stuff let's just take a look at the
interfaces we're going to create.
Here are the interfaces we're going to make will have ticket adders.
Again these are the properties that are required to build a ticket.
So we're gonna have title price and the user's I.D. will have ticket document which describes the properties
that ticket has now on this diagram I put created out right here.
We are not going to actually have created that that was just because I wanted you to have a reminder
of why we have a separate ticket adders and ticket dock interface ticket.
Ours is a set of properties required to build a record after the record is actually created and saved
and essentially turned it into a document.
That document might have some additional properties placed on it automatically by Mongoose and so an
example that might be that created at Flag and again that is why we had these two separate interfaces
because the final set of properties on safe record might be different than the set of properties that
required to create the record.
But again we won't have created that that was just a very quick reminder that the last interface will
be ticket model and once again we'll have a built method on there that's going to take in some attributes
and then return an actual document.
So with all this in mind with this review let's go back over to our editor.
We're going to start to build our ticket model.
All right inside of my tickets project I'll find the SRT directory I'll make a new folder inside they're
called models and then inside that ticket dot T.S. at the very top.
I will import Mongoose from Mongoose I'll then create those three different interfaces for the first
one will be ticket adders then ticket Doc and I'm going to write out the names of these to get started
and ticket model
all right.
That looks reasonable so I'm we're gonna go through an add in some actual properties to each of these.
So with ticket adders we're going to put in our title that's a string the price that is a number and
a user I.D. that's going to be a string
where that ticket document we're gonna add the exact same set of properties.
So again the only purpose of the thing is to have the possibility of adding in some additional properties
in the future.
So put in a title that's a no price and user I.D. We're also gonna make sure that the ticket document
interface extends Mongoose dot document.
And then finally for ticket model right here we're going to define that build function very similar
to what we had back inside of user model rails gonna make sure that we extend Mongoose dot model and
add on that generic type at the very end as well.
I'm going to put on extends Mongoose dot model with ticket Doc inside there it will define the build
method as taking in a set of attributes of type ticket adders and it's going to return a ticket doc.
All right.
So there's are three interfaces.
Let's take a quick pause right here and we'll start to define our ticket schema in the next video.