1
00:00:01,110 --> 00:00:02,950
We are onto our very last test here.

2
00:00:03,000 --> 00:00:07,890
So we need to make sure that if we send in some valid values and we are authenticated it ticket actually

3
00:00:07,890 --> 00:00:08,920
gets created.

4
00:00:09,090 --> 00:00:11,610
Once again let's write out the test for this first.

5
00:00:11,610 --> 00:00:15,360
So I think that the general request itself is going to maybe look something like this.

6
00:00:15,360 --> 00:00:18,910
Maybe something like a weight request to app.

7
00:00:19,050 --> 00:00:28,090
We want to do a post to API tickets and I want to send along some valid title so some string and a valid

8
00:00:28,090 --> 00:00:35,700
price of say 20 I'm going to say that if we successfully create a ticket I want to try to send back

9
00:00:35,730 --> 00:00:38,760
a status code up to a one indicating that a record was created.

10
00:00:39,450 --> 00:00:43,890
But by just asserting a two a one right here we're not actually checking to make sure that a ticket

11
00:00:43,890 --> 00:00:47,100
was created and saved to the database or anything like that.

12
00:00:47,160 --> 00:00:51,690
So I would really like if we could somehow write out some check inside of here to make sure that something

13
00:00:51,900 --> 00:00:54,380
was saved to the database.

14
00:00:54,560 --> 00:00:58,660
We don't really have anything inside of our tickets project just yet to work with the Mongo database

15
00:00:58,670 --> 00:01:02,870
that we've allocated so far right now I'm going to put in some comments to remind myself again to say

16
00:01:03,440 --> 00:01:09,550
add in a check to make sure a ticket was saved.

17
00:01:10,220 --> 00:01:15,370
So we will come back here very shortly and add something else in OK.

18
00:01:15,580 --> 00:01:19,120
So without a doubt the next you're going to have to work on to make sure that we can actually save a

19
00:01:19,120 --> 00:01:24,790
record to the database then eventually fetch some data or make sure that thing was saved is a ticket

20
00:01:24,880 --> 00:01:25,820
model.

21
00:01:25,930 --> 00:01:31,030
So remember we work with our Mongo DB database using mongoose in order to have Mongoose communicate

22
00:01:31,030 --> 00:01:31,840
with Mongo DV.

23
00:01:31,870 --> 00:01:37,630
We have to create a model and that model represents the collection of records we have inside of Mongo

24
00:01:37,630 --> 00:01:37,980
DB.

25
00:01:39,830 --> 00:01:43,480
Reading a mongoose model with type scripts is a little bit confusing.

26
00:01:43,520 --> 00:01:48,230
So let's go back over to our OTT service by the models directory and then the user test file inside

27
00:01:48,230 --> 00:01:54,120
there and just get a quick reminder on how we build a mongoose model with typescript to back over here.

28
00:01:54,140 --> 00:01:57,180
We had created those three interfaces at the very top.

29
00:01:57,290 --> 00:02:03,370
We had an interface that described the properties that were required to create a record the user dock

30
00:02:03,380 --> 00:02:04,100
right here.

31
00:02:04,190 --> 00:02:10,560
I'm skipping over the middle one the duck described these properties that a saved record had and then

32
00:02:10,560 --> 00:02:15,390
the model represented all the different properties that were going to be assigned to the model itself.

33
00:02:15,390 --> 00:02:19,100
And remember the model essentially represents the entire collection of data.

34
00:02:19,350 --> 00:02:22,820
The document represents one single record.

35
00:02:22,990 --> 00:02:26,970
We then created our schema which lists out all the properties we wanted.

36
00:02:26,980 --> 00:02:29,440
We also had a two Jason function side there.

37
00:02:29,470 --> 00:02:34,660
Remember too Jason was going to somehow manipulate the Jason representation this data.

38
00:02:34,660 --> 00:02:39,310
The most important thing we did inside of here beyond removing the password for our user in particular

39
00:02:39,700 --> 00:02:47,230
remember Mongo saves I.D. to a record as underscore I.D. That is super atypical not very standard.

40
00:02:47,230 --> 00:02:52,480
And so to make sure that we could have Mongo DB running as a back end database along with possibly other

41
00:02:52,480 --> 00:02:57,880
databases in the future we wanted to make sure that all of our Jason representation these records always

42
00:02:57,880 --> 00:03:02,160
presented the I.D. simply as I.D. as opposed to underscore I.D..

43
00:03:02,440 --> 00:03:08,880
So we're going to need to make sure that we do this for the ticket model we create as well after that.

44
00:03:08,880 --> 00:03:12,920
We then set up the pre safe hook that was only required because we were hashing a password.

45
00:03:12,960 --> 00:03:17,010
So that will not be needed on our ticket model.

46
00:03:17,050 --> 00:03:19,060
We then defined that build function.

47
00:03:19,060 --> 00:03:24,280
Remember the entire goal of this build function was to just allow typescript to do some validation or

48
00:03:24,280 --> 00:03:28,460
type checking on the properties we were trying to use to create a new record.

49
00:03:28,540 --> 00:03:34,180
That was the only reason we made built whenever we tried to create a record directly by using that user

50
00:03:34,180 --> 00:03:34,690
model.

51
00:03:34,690 --> 00:03:38,440
There's not any type shaking that goes on with the attributes we pass in.

52
00:03:38,470 --> 00:03:41,060
That's why we made this building after that.

53
00:03:41,090 --> 00:03:43,200
We create the actual model and then export it.

54
00:03:43,790 --> 00:03:48,650
We're going to do just about the exact same thing or a ticket model we're gonna write out the three

55
00:03:48,650 --> 00:03:55,490
interfaces the schema the build method insulin so for the ticket stuff let's just take a look at the

56
00:03:55,490 --> 00:03:57,440
interfaces we're going to create.

57
00:03:57,720 --> 00:04:01,930
Here are the interfaces we're going to make will have ticket adders.

58
00:04:01,930 --> 00:04:04,300
Again these are the properties that are required to build a ticket.

59
00:04:04,300 --> 00:04:09,850
So we're gonna have title price and the user's I.D. will have ticket document which describes the properties

60
00:04:09,850 --> 00:04:13,740
that ticket has now on this diagram I put created out right here.

61
00:04:13,780 --> 00:04:17,650
We are not going to actually have created that that was just because I wanted you to have a reminder

62
00:04:17,650 --> 00:04:22,480
of why we have a separate ticket adders and ticket dock interface ticket.

63
00:04:22,490 --> 00:04:27,490
Ours is a set of properties required to build a record after the record is actually created and saved

64
00:04:27,520 --> 00:04:30,130
and essentially turned it into a document.

65
00:04:30,130 --> 00:04:35,830
That document might have some additional properties placed on it automatically by Mongoose and so an

66
00:04:35,830 --> 00:04:40,960
example that might be that created at Flag and again that is why we had these two separate interfaces

67
00:04:41,320 --> 00:04:44,950
because the final set of properties on safe record might be different than the set of properties that

68
00:04:44,950 --> 00:04:46,360
required to create the record.

69
00:04:46,720 --> 00:04:51,490
But again we won't have created that that was just a very quick reminder that the last interface will

70
00:04:51,490 --> 00:04:55,560
be ticket model and once again we'll have a built method on there that's going to take in some attributes

71
00:04:55,590 --> 00:04:58,160
and then return an actual document.

72
00:04:58,200 --> 00:05:01,430
So with all this in mind with this review let's go back over to our editor.

73
00:05:01,440 --> 00:05:05,550
We're going to start to build our ticket model.

74
00:05:05,660 --> 00:05:12,510
All right inside of my tickets project I'll find the SRT directory I'll make a new folder inside they're

75
00:05:12,510 --> 00:05:19,900
called models and then inside that ticket dot T.S. at the very top.

76
00:05:19,910 --> 00:05:27,360
I will import Mongoose from Mongoose I'll then create those three different interfaces for the first

77
00:05:27,360 --> 00:05:34,110
one will be ticket adders then ticket Doc and I'm going to write out the names of these to get started

78
00:05:35,590 --> 00:05:36,940
and ticket model

79
00:05:41,290 --> 00:05:41,860
all right.

80
00:05:41,950 --> 00:05:46,660
That looks reasonable so I'm we're gonna go through an add in some actual properties to each of these.

81
00:05:46,660 --> 00:05:52,630
So with ticket adders we're going to put in our title that's a string the price that is a number and

82
00:05:52,630 --> 00:05:54,520
a user I.D. that's going to be a string

83
00:05:57,310 --> 00:06:00,380
where that ticket document we're gonna add the exact same set of properties.

84
00:06:00,400 --> 00:06:05,140
So again the only purpose of the thing is to have the possibility of adding in some additional properties

85
00:06:05,140 --> 00:06:06,060
in the future.

86
00:06:06,220 --> 00:06:14,810
So put in a title that's a no price and user I.D. We're also gonna make sure that the ticket document

87
00:06:14,840 --> 00:06:23,020
interface extends Mongoose dot document.

88
00:06:23,230 --> 00:06:29,060
And then finally for ticket model right here we're going to define that build function very similar

89
00:06:29,060 --> 00:06:35,960
to what we had back inside of user model rails gonna make sure that we extend Mongoose dot model and

90
00:06:35,960 --> 00:06:38,680
add on that generic type at the very end as well.

91
00:06:43,110 --> 00:06:52,670
I'm going to put on extends Mongoose dot model with ticket Doc inside there it will define the build

92
00:06:52,670 --> 00:07:04,500
method as taking in a set of attributes of type ticket adders and it's going to return a ticket doc.

93
00:07:04,600 --> 00:07:04,830
All right.

94
00:07:04,840 --> 00:07:07,100
So there's are three interfaces.

95
00:07:07,270 --> 00:07:11,630
Let's take a quick pause right here and we'll start to define our ticket schema in the next video.