1 00:00:01,120 --> 00:00:02,670 We're inside of our order created a listener. 2 00:00:02,710 --> 00:00:07,480 So any time this thing gets called presumably we need to find the associated ticket and somehow lock 3 00:00:07,480 --> 00:00:08,220 it down. 4 00:00:08,230 --> 00:00:12,120 So in this video we're gonna figure out well how are we going to somehow lock down a ticket. 5 00:00:12,160 --> 00:00:15,580 This might seem like a really obvious problem with some obvious solution. 6 00:00:15,700 --> 00:00:19,630 You might say all right for all the different tickets inside of our ticket service let's add on some 7 00:00:19,630 --> 00:00:23,280 kind of a locked property or something similar to that. 8 00:00:23,470 --> 00:00:27,550 We'll make that a boolean and if locked is set to true that means the ticket is locked and we should 9 00:00:27,550 --> 00:00:30,290 not allow anyone to make any changes to it. 10 00:00:30,400 --> 00:00:34,890 And then whenever we see the order canceled event we can flip locked back over to false. 11 00:00:34,900 --> 00:00:37,970 Which means now people can edit his ticket once again. 12 00:00:38,020 --> 00:00:43,240 This seems like a pretty obvious straightforward solution that a doubt but I could suggest maybe if 13 00:00:43,240 --> 00:00:48,310 we start to think forward a little bit about some other capabilities that we're going to maybe eventually 14 00:00:48,310 --> 00:00:53,020 want to have inside our application we will realize that just having a simple boolean maybe not the 15 00:00:53,020 --> 00:00:59,380 best thing in the world so I want you to imagine the following scenario if we made use of some simple 16 00:00:59,380 --> 00:01:02,570 boolean to track whether or not a ticket is locked. 17 00:01:02,590 --> 00:01:05,550 Let's imagine that some user who actually owns this ticket. 18 00:01:05,560 --> 00:01:08,510 So this is the person who is trying to sell this ticket. 19 00:01:08,530 --> 00:01:13,390 Once you figure out what the status of their ticket is they might make some kind of request to our ticket 20 00:01:13,390 --> 00:01:16,260 service asking Is someone buying my ticket. 21 00:01:16,300 --> 00:01:17,540 Is this thing getting sold. 22 00:01:17,560 --> 00:01:24,230 What is the state of the ticket if we were only recording this locked flag right here as true or false. 23 00:01:24,230 --> 00:01:27,530 Then we can really only say something like this as a response. 24 00:01:27,530 --> 00:01:30,040 We can probably say yes the tickets locked. 25 00:01:30,050 --> 00:01:34,010 Which means it's being purchased but we have no idea who is purchasing it. 26 00:01:34,010 --> 00:01:40,740 No clue what so whatsoever and that probably would not be a great response to come back to some one 27 00:01:40,740 --> 00:01:42,210 who is ordering the ticket. 28 00:01:42,210 --> 00:01:46,080 Imagine if you were selling something and you were selling it through some Web site and you want to 29 00:01:46,080 --> 00:01:48,890 find out what the status of your thing that you're selling is. 30 00:01:48,990 --> 00:01:50,220 And the website just told you. 31 00:01:50,250 --> 00:01:54,940 Yeah we think someone's buying it but we've got no idea what's going on with that transaction whatsoever. 32 00:01:54,960 --> 00:01:56,140 Not a great response. 33 00:01:56,830 --> 00:02:00,330 So rather than just recording this very simple flag right here of locked. 34 00:02:00,330 --> 00:02:01,630 True or false. 35 00:02:01,740 --> 00:02:06,330 We're going to instead record the order I.D. that is tied to the ticket. 36 00:02:06,610 --> 00:02:08,410 So this is going to be the order. 37 00:02:08,610 --> 00:02:12,250 Just the idea of it that is somehow reserving this ticket. 38 00:02:12,400 --> 00:02:16,170 And once you have that information getting some information about the status the ticket is going to 39 00:02:16,170 --> 00:02:18,320 be a lot more straightforward. 40 00:02:18,420 --> 00:02:23,100 Now someone who owns a ticket can make a request and say Is someone buying my ticket and will send back 41 00:02:23,100 --> 00:02:29,430 some response that says yeah someone is buying it and the order I.D. that represents the person who 42 00:02:29,430 --> 00:02:34,780 is trying to buy the thing is maybe less than this person who owns the ticket could make a followup 43 00:02:34,800 --> 00:02:38,560 request overture order service and very easily say what is the status of order. 44 00:02:38,590 --> 00:02:42,990 Yes and maybe it is currently awaiting payment so we could send that back to the user and say yeah we're 45 00:02:42,990 --> 00:02:46,850 just waiting for someone to pay for the thing and then you'll get your money from the ticket being sold 46 00:02:48,350 --> 00:02:52,390 but this is a little bit more kind of forward thinking approach even though it is a little bit greater 47 00:02:52,390 --> 00:02:55,540 complexity now a little bit of specifics here. 48 00:02:55,600 --> 00:03:00,920 We're going to use the presence of an order I.D. to decide whether or not a ticket is currently reserved. 49 00:03:00,940 --> 00:03:06,430 And so whether or not we should prevent edits to it by default all tickets will be created with a null 50 00:03:06,460 --> 00:03:09,700 value for order I.D. So if there is no order I.D.. 51 00:03:09,730 --> 00:03:15,100 That means that the ticket is not reserved and we should allow edits but as soon as there is an order 52 00:03:15,100 --> 00:03:18,490 I.D. Now the thing should be locked prevent edits. 53 00:03:18,490 --> 00:03:22,720 The other thing I want to mention very quickly in passing here is technically the order I.D. is not 54 00:03:22,720 --> 00:03:26,910 strictly necessary to look up the status of some order that is tied to a ticket. 55 00:03:26,920 --> 00:03:32,680 Technically we could just take this ticket idea right here and maybe create a new endpoint inside of 56 00:03:32,680 --> 00:03:37,900 our order service to take a ticket I.D. and return some information about the order that is associated 57 00:03:37,900 --> 00:03:42,280 with that ticket because the order service does know all these different ticket ideas that would definitely 58 00:03:42,280 --> 00:03:45,390 a possibility but we don't actually have a root handler for that right now. 59 00:03:45,400 --> 00:03:50,560 We would have to build out some separate functionality to say hey give us a ticket idea we'll find the 60 00:03:50,560 --> 00:03:54,580 appropriate order associated with that thing if it actually exists. 61 00:03:54,580 --> 00:03:59,350 If we instead just make use of this order I.D. system keep track of the audience that ticket service 62 00:03:59,590 --> 00:04:03,190 then we can actually reuse some existing code that we already have inside the order service. 63 00:04:03,190 --> 00:04:08,800 We already have a root handler that is setup to return a order given an I.D. that's already been put 64 00:04:08,800 --> 00:04:14,170 together and so it would be really easy to reuse that code as opposed to have to write an entirely new 65 00:04:14,210 --> 00:04:19,480 endpoint to retrieve an order based upon a ticket ideologue OK. 66 00:04:19,520 --> 00:04:19,910 That's it. 67 00:04:19,910 --> 00:04:21,380 That's how we're going to lock down a ticket. 68 00:04:21,740 --> 00:04:23,900 So what does that really mean in practice. 69 00:04:23,900 --> 00:04:30,290 Well it means that inside of on message I here whenever we are told that an order has been created we're 70 00:04:30,290 --> 00:04:34,040 going to take out of this event right here and if we forget what is actually defined in it we always 71 00:04:34,040 --> 00:04:39,620 do that comment click so the idea right here is the idea the order that was created and more importantly 72 00:04:39,650 --> 00:04:42,680 we've also got the information about the ticket those create as well. 73 00:04:42,680 --> 00:04:44,640 Specifically the ideas. 74 00:04:44,870 --> 00:04:50,430 So instead of on message we're going to take that I.D. instead of on message. 75 00:04:50,440 --> 00:04:54,700 We're then going to use that to fetch some ticket out of our tickets collection. 76 00:04:54,700 --> 00:04:59,560 And then on the ticket model or ticket document we're going to store the order I.D. from also inside 77 00:04:59,560 --> 00:05:05,810 this order created events so we're going to store that order I.D. inside of the ticket in our ticket 78 00:05:05,810 --> 00:05:06,530 service. 79 00:05:06,530 --> 00:05:10,730 Well we're also going to have to open up our models ticket to us file and just make sure that we add 80 00:05:10,730 --> 00:05:14,870 in the idea of a ticket having an order idea property. 81 00:05:14,930 --> 00:05:19,940 So in total we're going to make a quick change the ticket model file and then write out some logic inside 82 00:05:19,940 --> 00:05:21,080 the order creating listener. 83 00:05:21,110 --> 00:05:25,810 And that's pretty much it that's now that we've got a overview on what's going on here. 84 00:05:25,810 --> 00:05:27,730 Let's start the implementation in the next video.