1 00:00:01,650 --> 00:00:03,900 We're doing some validation on the incoming request. 2 00:00:03,930 --> 00:00:07,330 So now we need to start to think about the body of this request handler. 3 00:00:07,380 --> 00:00:11,970 Remember the entire goal of this request handler is to take in some information about a ticket that 4 00:00:11,970 --> 00:00:19,190 the user is trying to purchase and then create an order record and save in order to our Mongo DB database. 5 00:00:19,190 --> 00:00:23,400 Any time we'd talk about saving information to our database that always means so we need to create a 6 00:00:23,400 --> 00:00:24,990 mongoose model. 7 00:00:24,990 --> 00:00:28,200 Right now our orders project does not have any models tied to it. 8 00:00:28,200 --> 00:00:32,820 So before we can continue with building out this request HANDLER We have to create a mongoose model 9 00:00:32,850 --> 00:00:35,340 to describe what in order is. 10 00:00:35,350 --> 00:00:39,300 So in this video we're going to tackle a bit more about exactly what an order is and how we're going 11 00:00:39,300 --> 00:00:41,720 to model it inside of our database. 12 00:00:41,860 --> 00:00:42,130 All right. 13 00:00:42,140 --> 00:00:45,390 So back in this diagram over here we're talking about the order service. 14 00:00:45,410 --> 00:00:49,700 We said that this thing was going to have a collection of orders in every order would have a user I.D. 15 00:00:49,790 --> 00:00:58,030 status expires that and it would also somehow reference a ticket as well so when we talk about saving 16 00:00:58,060 --> 00:00:59,400 orders to the database. 17 00:00:59,440 --> 00:01:04,510 Well inevitably we also need to think about how we're going to save tickets to the database and most 18 00:01:04,510 --> 00:01:07,860 importantly how we're going to relate these two things together. 19 00:01:08,050 --> 00:01:10,260 And that's what I really want to discuss in this video. 20 00:01:10,330 --> 00:01:16,590 How are we going to somehow relate an order to a ticket so we need to associate these two things together 21 00:01:16,590 --> 00:01:17,300 somehow. 22 00:01:17,580 --> 00:01:22,980 We're going to have inside of our database presumably in some fashion a collection of different tickets 23 00:01:22,980 --> 00:01:24,460 that are available to be purchased. 24 00:01:24,570 --> 00:01:29,040 And once the user tries to create an order we need to somehow mark that ticket as being reserved or 25 00:01:29,040 --> 00:01:34,910 associated with a very particular order so we start to discuss associating records together with Mongo 26 00:01:34,910 --> 00:01:35,530 DB. 27 00:01:35,540 --> 00:01:40,910 There are two primary strategies that we can use so we can take a look at the two primary strategies 28 00:01:40,910 --> 00:01:47,740 we can use to associate in order with a ticket So option number one or strategy number one is referred 29 00:01:47,740 --> 00:01:54,320 to as embedding with him and Bettman strategy we might have an order like this right here. 30 00:01:54,320 --> 00:01:56,100 So this would be an order document. 31 00:01:56,290 --> 00:02:01,630 We would have the user I.D. status expires out and then to somehow associate an order with a ticket. 32 00:02:01,700 --> 00:02:06,290 We could embed the information about that ticket directly inside the order itself. 33 00:02:06,770 --> 00:02:12,450 So in other words you would have a ticket property and that would be a plane object with some I.D. some 34 00:02:12,470 --> 00:02:15,260 price for the ticket and some title as well. 35 00:02:15,320 --> 00:02:20,020 This would make it really easy to figure out what orders are concerned with what tickets. 36 00:02:20,350 --> 00:02:25,640 So we can very easily look up and order and say ah right here on the ticket property this is the ticket 37 00:02:25,640 --> 00:02:28,030 that the user is attempting to purchase. 38 00:02:28,040 --> 00:02:30,790 So this is one way that we can associate orders and tickets together. 39 00:02:30,800 --> 00:02:36,370 But there are some definite big downsides to it for our particular application. 40 00:02:36,620 --> 00:02:42,920 So here's ups or bet downside at number one whenever a user tries to make a request to create an order 41 00:02:43,710 --> 00:02:48,920 we need to make sure that that ticket that they're trying to order is not already reserved. 42 00:02:49,040 --> 00:02:54,560 So if we start to embed these tickets inside of each order making sure that a ticket is not already 43 00:02:54,560 --> 00:02:58,730 reserved is going to start to get just a little bit challenging to query as we're going to essentially 44 00:02:58,730 --> 00:03:02,390 have to take a look at all the different orders that have been created over time. 45 00:03:02,390 --> 00:03:05,780 Take a look at the tickets embedded inside of each one. 46 00:03:05,780 --> 00:03:11,450 Take a look at the idea and make sure that I.D. is not equal to the idea that is inside of this incoming 47 00:03:11,510 --> 00:03:17,500 request if an idea is already listed inside of an existing order or if a ticket is already list inside 48 00:03:17,500 --> 00:03:18,530 of an existing order. 49 00:03:18,550 --> 00:03:20,400 That means the ticket would be in use. 50 00:03:20,500 --> 00:03:25,690 So downside number 1 to option number one is that query to make sure that ticket is not in use just 51 00:03:25,720 --> 00:03:31,630 a little bit challenging but there is a way bigger downside something that makes this embedding approach 52 00:03:31,660 --> 00:03:37,030 just about impossible to implement for our particular application. 53 00:03:37,100 --> 00:03:42,430 Remember we're going to have our ticket service and that's going to eventually emit events like ticket 54 00:03:42,430 --> 00:03:44,500 created and ticket updated. 55 00:03:44,500 --> 00:03:47,550 These events will be received by the order service. 56 00:03:47,740 --> 00:03:52,390 Now every ticket that gets created is not going to be immediately assigned to an order. 57 00:03:52,450 --> 00:03:57,400 There will be some point time where someone creates a ticket to sell and then it's just listed on our 58 00:03:57,420 --> 00:03:59,290 website waiting for someone to purchase it. 59 00:03:59,800 --> 00:04:06,610 So we need a way to essentially have tickets represented or an inside of our order service without actually 60 00:04:06,610 --> 00:04:09,870 associating them directly with an order. 61 00:04:09,880 --> 00:04:14,650 In other words there has to be a separate pool a pool of records that say here's a list of all the tickets 62 00:04:14,650 --> 00:04:21,500 that no one has tried to purchase yet so this option number one strategy where we embed tickets inside 63 00:04:21,500 --> 00:04:27,220 of an order document really just not feasible because we really cannot have some kind of standby pool 64 00:04:27,220 --> 00:04:30,200 of tickets that are waiting to be purchased. 65 00:04:30,200 --> 00:04:32,330 So we're not going to be making use of embedding. 66 00:04:32,410 --> 00:04:34,590 Instead we're going to take a look at a different strategy. 67 00:04:34,600 --> 00:04:36,600 So this is kind of general strategy. 68 00:04:36,610 --> 00:04:40,790 Number two we're associating records with Mongo deeds and mongoose. 69 00:04:40,930 --> 00:04:47,590 We're going to use a feature inside a mongoose called the ref or population feature so the ref or a 70 00:04:47,590 --> 00:04:50,470 population feature however you want to refer to it. 71 00:04:50,470 --> 00:04:57,160 We're going to have a collection of documents about orders and a collection of documents about tickets. 72 00:04:57,160 --> 00:05:04,160 So a orders collection and a ticket collection then inside of every order they can optionally have a 73 00:05:04,160 --> 00:05:06,050 reference to a ticket. 74 00:05:06,050 --> 00:05:10,880 So we will have some ticket property and this will essentially somehow be a reference over to a ticket 75 00:05:11,090 --> 00:05:15,980 inside of our tickets collection so two separate collections. 76 00:05:16,000 --> 00:05:21,100 This will make it really easy for us to query all the different tickets and figure out if a given ticket 77 00:05:21,130 --> 00:05:22,610 is in use or not. 78 00:05:22,630 --> 00:05:27,400 We can also very easily find all the different tickets that are still awaiting to be purchased and list 79 00:05:27,400 --> 00:05:30,870 them out separately on the react side of our application as well. 80 00:05:33,210 --> 00:05:37,710 So this is the strategy we're going to use we're going to use the ref or population feature. 81 00:05:37,930 --> 00:05:42,570 Now the reason I'm making such a real big deal around this stuff you know when we looked at this diagram 82 00:05:42,570 --> 00:05:45,270 over here it might have already been kind of obvious to you. 83 00:05:45,540 --> 00:05:46,370 Oh yeah okay. 84 00:05:46,390 --> 00:05:48,280 Or collection of orders collection tickets. 85 00:05:48,300 --> 00:05:51,300 And so this video might seem a little bit unnecessary. 86 00:05:51,300 --> 00:05:56,340 The big reason I'm giving you this explanation is that later on this relationship that we're setting 87 00:05:56,340 --> 00:06:00,570 up for some features we're going to build in a little bit is actually going to become really really 88 00:06:00,570 --> 00:06:01,910 really important. 89 00:06:01,980 --> 00:06:07,080 And on top of that setting up this relationship with Mongoose where we have some ticket property on 90 00:06:07,080 --> 00:06:11,070 the order document referring to a ticket there's actually a little trick or two that you need to be 91 00:06:11,070 --> 00:06:13,320 aware of around that as well. 92 00:06:13,440 --> 00:06:18,070 So that's why we did this kind of extra video just to kind of clarify the relationship between the stuff. 93 00:06:18,120 --> 00:06:23,190 So at the end the day the strategy that we're going to be forward with we're going to have a collection 94 00:06:23,190 --> 00:06:28,890 of orders a collection of tickets we're going to relate the two together or associate the two together 95 00:06:29,190 --> 00:06:31,770 using this ref or population feature. 96 00:06:32,010 --> 00:06:34,280 I'll show you how this feature works if you're not familiar with it. 97 00:06:34,350 --> 00:06:38,130 Otherwise you can always take a look at the Mongoose documentation and understand a little bit more 98 00:06:38,130 --> 00:06:39,790 about how it works. 99 00:06:39,990 --> 00:06:40,680 Quick pause right here. 100 00:06:40,680 --> 00:06:45,090 When we come back the next video we're gonna start to write out an implementation or our order document 101 00:06:45,430 --> 00:06:49,020 and then the ticket document right after that so quick possible see you in just a minute.