1 00:00:01,190 --> 00:00:03,480 Let's grade our bottle to represent a ticket. 2 00:00:03,560 --> 00:00:07,790 We're gonna put together a new model file that's gonna be just about identical to all the order stuff 3 00:00:07,820 --> 00:00:09,860 we just wrote out in my model's directory. 4 00:00:09,860 --> 00:00:12,770 I'll make a new file called Ticket dot T.S. at the top. 5 00:00:12,770 --> 00:00:21,820 I will import Mongoose from Mongoose and then we'll create our three interfaces right away. 6 00:00:22,090 --> 00:00:29,640 We'll get an interface of ticket adders and interface of ticket doc which is going to extend Mongoose 7 00:00:29,640 --> 00:00:39,500 dot document and an interface of ticket model which is going to extend longest out model and we'll load 8 00:00:39,490 --> 00:00:42,710 it as a generic ticket doc now. 9 00:00:42,730 --> 00:00:47,730 At this point this is the first time that we are really seeing replication of data between services. 10 00:00:47,810 --> 00:00:53,120 We have already written out code that looks just about identical to this inside of our tickets service. 11 00:00:53,130 --> 00:00:58,460 So you might be curious can we extract this code into our common shared library and then use that inside 12 00:00:58,460 --> 00:01:00,740 of both these services orders and tickets. 13 00:01:00,740 --> 00:01:05,770 The answer is definitely definitely not definitely to want to do it. 14 00:01:05,810 --> 00:01:10,460 What we are writing right here is a implementation or essentially code to save data to the database. 15 00:01:10,610 --> 00:01:15,020 And this could potentially be very specific to the service that we are working in right now. 16 00:01:15,020 --> 00:01:19,580 So we are going to put some attributes inside of here that are just attributes that the order service 17 00:01:19,640 --> 00:01:21,970 alone needs to work correctly. 18 00:01:21,980 --> 00:01:26,880 The only thing that the order service really needs to know about a given ticket is you go backwards 19 00:01:26,920 --> 00:01:32,820 to this diagram the tickets title price and that version thing as well. 20 00:01:32,870 --> 00:01:36,020 Technically also idea I'm just not showing it on this diagram. 21 00:01:36,020 --> 00:01:41,360 There might be a tremendous number of additional pieces of information tied to a ticket that gets saved 22 00:01:41,360 --> 00:01:46,100 inside of the ticket service but the order service doesn't care about all those additional properties 23 00:01:46,100 --> 00:01:47,490 that may or may not exist. 24 00:01:47,570 --> 00:01:54,170 The order service only cares about title Price version and I.T. that's it nothing else. 25 00:01:54,170 --> 00:02:00,170 So we definitely want to have different definitions of what a ticket is between orders and tickets. 26 00:02:00,170 --> 00:02:05,450 Beyond that our order service might eventually grow to encapsulate things that can be ordered or purchased 27 00:02:05,660 --> 00:02:07,250 besides just tickets. 28 00:02:07,250 --> 00:02:13,220 So maybe we can also purchase say parking spot or something like that like a parking pass or something 29 00:02:13,480 --> 00:02:15,770 for some sporting event or what have you. 30 00:02:15,830 --> 00:02:20,180 We would probably want to encapsulate that logic under this order service as well and allow a user to 31 00:02:20,240 --> 00:02:26,420 order a parking pass but a parking pass might have a very different set of attributes than a ticket 32 00:02:27,450 --> 00:02:32,430 so we would not want to essentially lock down the definition of what a ticket is between the order service 33 00:02:32,460 --> 00:02:33,550 and the ticket service. 34 00:02:33,630 --> 00:02:38,310 And that's why we're definitely to make sure that we do not try to share the definition of exactly what 35 00:02:38,310 --> 00:02:39,210 a ticket is. 36 00:02:39,270 --> 00:02:42,690 As it gets saved to the database between these different services. 37 00:02:42,750 --> 00:02:45,980 So that might let's continue on our implementation right here. 38 00:02:46,020 --> 00:02:50,520 So on the ticket we want to have a title price and we're not gonna worry about the version just yet. 39 00:02:50,520 --> 00:02:53,070 No that's has to do with that concurrency stuff. 40 00:02:53,140 --> 00:02:57,700 We're going to come back to that once we have the ability to actually see the concurrency stuff fail. 41 00:02:57,830 --> 00:03:04,500 So right now on it ticket adders we're gonna have only a title that has a string a price that is a number 42 00:03:05,810 --> 00:03:07,540 scenting on our ticket docket right now. 43 00:03:07,540 --> 00:03:12,890 So titled as a string price that is a number and then ticket model. 44 00:03:12,890 --> 00:03:15,350 Once again we're gonna have that method of built 45 00:03:18,090 --> 00:03:25,270 this thing is gonna get some adders that are of type ticket adders and it's going to return a ticket 46 00:03:25,570 --> 00:03:29,160 Doc lets them build out our schema 47 00:03:34,260 --> 00:03:35,570 on the first object inside of here. 48 00:03:35,580 --> 00:03:40,020 Let's list out all the different properties we want to have the persisted to our database. 49 00:03:40,020 --> 00:03:44,250 So we'll put in a title that is of type capital s String. 50 00:03:44,250 --> 00:03:46,200 Don't forget that capital on there. 51 00:03:46,200 --> 00:03:54,330 We definitely want to make sure that this thing is required and then a price there's gonna be a type 52 00:03:54,330 --> 00:04:00,190 of number we'll say this thing is required true and we're going to assume that the price should always 53 00:04:00,190 --> 00:04:01,240 be positive. 54 00:04:01,330 --> 00:04:08,570 Looking gonna put in a minimum price of 0 we do also have to define that to Jason method here as well. 55 00:04:08,610 --> 00:04:17,910 So as the second argument we'll put in another object defined to Jason you are transform receive Doc 56 00:04:17,940 --> 00:04:19,100 and the return value. 57 00:04:19,700 --> 00:04:21,720 And once again let's dump IDI 58 00:04:25,280 --> 00:04:28,160 delete Rhett underscore he looks good. 59 00:04:29,760 --> 00:04:35,640 After that we'll define that build method ticket schema 60 00:04:38,930 --> 00:04:40,740 come on ticket schema. 61 00:04:40,760 --> 00:04:42,120 There we go. 62 00:04:42,140 --> 00:04:43,580 Static stop builds. 63 00:04:43,720 --> 00:04:50,020 Taken a set of attributes which are of type ticket adders and then return a new ticket. 64 00:04:54,030 --> 00:04:55,140 With those adders 65 00:04:58,810 --> 00:05:03,880 I'm getting an air around ticket schema which makes me think I might call the thing just schema up here. 66 00:05:03,880 --> 00:05:06,200 We can stay consistent one way or the other. 67 00:05:06,220 --> 00:05:08,860 I'll change the variable up here to ticket schema 68 00:05:11,770 --> 00:05:15,130 so I've got ticket schema right there consistent with ticket schema right there. 69 00:05:16,970 --> 00:05:25,480 Then after that we will define the actual model so ticket is Mongoose dot model row in the document 70 00:05:25,480 --> 00:05:34,560 type the model type we want to say this in a collection called Ticket throw in the schema as the second 71 00:05:34,560 --> 00:05:36,810 argument. 72 00:05:36,980 --> 00:05:38,180 And then finally we will export 73 00:05:41,600 --> 00:05:43,850 now little gotcha here back inside of order. 74 00:05:43,860 --> 00:05:49,650 We need to import into this order file the definition of what a ticket document is so that all these 75 00:05:49,650 --> 00:05:51,930 interfaces actually work. 76 00:05:51,930 --> 00:05:54,490 So we need to go back to our ticket file that we just put together. 77 00:05:54,540 --> 00:05:58,740 We're going up to the very top where we defined that interface of what a ticket document is. 78 00:05:58,830 --> 00:06:03,960 We'll make sure that we export that so we can import it over into the order so I make sure I get export 79 00:06:03,960 --> 00:06:04,560 right there. 80 00:06:04,580 --> 00:06:10,360 I'm going to say this file will then go backwards in the order model file and at the top let's import 81 00:06:11,110 --> 00:06:15,860 ticket doc from ticket and there we go. 82 00:06:18,950 --> 00:06:20,770 So now I've got the ability to create a ticket. 83 00:06:20,960 --> 00:06:22,370 We can save tickets to the database. 84 00:06:22,370 --> 00:06:27,260 We can load them once we have an instance of a ticket we can assign that ticket to an order either when 85 00:06:27,260 --> 00:06:31,020 it gets created because remember this interface is described in the properties that go into creating 86 00:06:31,040 --> 00:06:37,030 order and we can also assign a ticket to an order instance as well or an order document. 87 00:06:37,040 --> 00:06:40,440 Remember this interface is about an instance of an order. 88 00:06:40,610 --> 00:06:40,860 All right. 89 00:06:40,870 --> 00:06:45,030 So I know at this point time a lot of stuff probably still you know as with many things in this course 90 00:06:45,300 --> 00:06:47,020 probably seems all a bit nasty. 91 00:06:47,040 --> 00:06:51,570 Trust me as soon as we start to write out a little bit more code here and we start to run into issues 92 00:06:51,630 --> 00:06:56,700 specifically around some concurrency stuff and event handling you're gonna start to see it really quickly 93 00:06:56,940 --> 00:07:03,300 on why we've got these two separate models why we are using this kind of population stuff and a lot 94 00:07:03,300 --> 00:07:05,280 of other things are going to start to become clear. 95 00:07:05,400 --> 00:07:07,030 So let's take a pause right here. 96 00:07:07,110 --> 00:07:08,730 Continue chugging on in the next video.