1 00:00:01,490 --> 00:00:06,230 Well we definitely have to accept some of these concurrency issues but as usual I'm still not entirely 2 00:00:06,230 --> 00:00:08,390 happy with our implementation. 3 00:00:08,390 --> 00:00:11,220 I think there are one or two things that we could definitely improve upon. 4 00:00:11,240 --> 00:00:16,070 The first I want to point out inside of our ticket update a listener we've got this really ugly query 5 00:00:16,070 --> 00:00:16,690 here now. 6 00:00:16,860 --> 00:00:21,770 You've got to find one where you have to add in this somewhat complicated set of filters as you can 7 00:00:21,770 --> 00:00:25,970 imagine duplicating this around to a bunch of other listeners in the future with start to get really 8 00:00:25,970 --> 00:00:28,010 tiring really quickly. 9 00:00:28,010 --> 00:00:32,840 Not only is there this kind of mysterious underscore I.D. where we've been trying to stick to this I.D. 10 00:00:32,840 --> 00:00:37,670 convention quite a bit but we also have this data version minus one. 11 00:00:37,790 --> 00:00:42,050 And it's really likely in my opinion that some other engineers are going to look at this minus one at 12 00:00:42,050 --> 00:00:47,210 some point time and say why would we subtract minus one let's dump that and if we did that everything 13 00:00:47,210 --> 00:00:48,440 would start to break. 14 00:00:48,440 --> 00:00:52,700 So putting the minus one in here I don't really like having to break out these two separate properties 15 00:00:52,700 --> 00:00:53,750 of ideal version. 16 00:00:53,840 --> 00:00:54,750 Also not great. 17 00:00:54,770 --> 00:00:58,130 Long story short I think we can do better than this. 18 00:00:58,240 --> 00:01:02,380 So we're going to build a little helper method on our ticket model directly. 19 00:01:02,570 --> 00:01:07,880 This ticket model is going to take in this entire data object right here and then essentially do the 20 00:01:07,880 --> 00:01:13,100 exact same query but we're just going to kind of wrap everything else everything up and hide away these 21 00:01:13,160 --> 00:01:19,650 nasty implementation details such as underscore I.D. and data version minus one so to get started instead 22 00:01:19,680 --> 00:01:20,570 of my order service. 23 00:01:20,570 --> 00:01:27,690 I'll find the models directory ticket dot yes I'll then find my ticket model there's the ticket model 24 00:01:27,780 --> 00:01:33,600 interface to be precise we're going to add in a new method directly to the model itself that's going 25 00:01:33,600 --> 00:01:40,440 to just facilitate us in doing a query for a I.D. plus a version the inside of here inside the ticket 26 00:01:40,440 --> 00:01:47,820 model interface I'm going to add in a new query method we'll call it How about find by event not the 27 00:01:47,820 --> 00:01:49,810 best name really. 28 00:01:49,830 --> 00:01:51,150 Maybe there's a better name. 29 00:01:51,150 --> 00:01:56,880 I don't only want to call it find by I.D. And version because we're not really finding by version we're 30 00:01:57,300 --> 00:02:00,150 doing a find by I.D. and previous version. 31 00:02:00,150 --> 00:02:05,410 And so that would lead us to a name of something like that which is just way too long in my opinion. 32 00:02:05,610 --> 00:02:11,010 It certainly is clear about what's going on but I don't know I'm going to just stick with find by events 33 00:02:11,610 --> 00:02:16,050 and the assumption here is I'm going to pass in some kind of event or data object. 34 00:02:16,170 --> 00:02:20,580 This method will pull off the I.D. And version properties subtract one from the version and use that 35 00:02:20,580 --> 00:02:26,330 to run the same query we had wrote written just a moment ago so let's say that this is going to receive 36 00:02:26,330 --> 00:02:32,590 some kind of event ish object and I'll just put a type of notation for it right here directly in line. 37 00:02:32,600 --> 00:02:40,490 I'll say that whatever we pass in must have an I.D. that is a string and a version that is a number 38 00:02:42,060 --> 00:02:50,840 and then from this we're going to return a promise that is going to resolve with either a ticket doc 39 00:02:51,320 --> 00:02:52,350 or no. 40 00:02:52,670 --> 00:02:57,740 That's how we would express that will either actually find a ticket document or we won't find anything 41 00:02:57,800 --> 00:03:00,490 matching this idea and version criteria. 42 00:03:00,610 --> 00:03:06,280 So that would be our invitation for the return type now to actually implement this method. 43 00:03:06,310 --> 00:03:07,570 We'll scroll down a little bit. 44 00:03:07,570 --> 00:03:09,700 We already went through this process with the build method. 45 00:03:09,700 --> 00:03:16,570 All we have to do is add a new function to the statics object so I'll add in ticket schema that statics 46 00:03:16,900 --> 00:03:27,270 that bind by event and we'll write out our implementation so this will take that same kind of data object 47 00:03:27,300 --> 00:03:33,250 or event object whatever we want to call it all that matters is that it has an I.D. that is a string 48 00:03:34,310 --> 00:03:39,660 and a version that is a number then inside of here all we're really going to do is run the same query 49 00:03:39,720 --> 00:03:48,560 we had just put together inside of our listener so I will return ticket not find one. 50 00:03:48,670 --> 00:03:57,720 We're gonna look for underscore ideas equal to event thought i.e. and a version equal to version minus 51 00:03:57,720 --> 00:04:00,730 one or event dog person 52 00:04:04,080 --> 00:04:10,680 and that should be it so I'll say this file I'm then going to go back over to our listener and now we 53 00:04:10,680 --> 00:04:15,120 can clean up this query right here and hide away these kind of nasty details they're going to turn this 54 00:04:15,120 --> 00:04:24,210 entire thing into a weight ticket dot bind by event and I'll pass in that data object like so 55 00:04:28,580 --> 00:04:30,250 what we should probably do another quick test. 56 00:04:30,250 --> 00:04:31,290 So going to save this. 57 00:04:31,330 --> 00:04:35,860 And once again go to the process of creating a ticket and updating it. 58 00:04:35,860 --> 00:04:40,480 Alternatively we could just try to make another update to the ticket we had made an update to just a 59 00:04:40,480 --> 00:04:41,140 moment ago. 60 00:04:41,200 --> 00:04:44,650 I think that would actually be the best because now we can actually test make sure everything works 61 00:04:44,650 --> 00:04:46,980 with incrementing version numbers as well. 62 00:04:47,020 --> 00:04:49,090 I've still got the previous ticket I had created. 63 00:04:49,090 --> 00:04:49,570 Actually no. 64 00:04:49,630 --> 00:04:53,220 I don't personally because I just deleted all my tickets in the last video. 65 00:04:53,260 --> 00:04:57,700 Too bad for me but for you absolutely you can try to make the same post request and then go back over 66 00:04:57,700 --> 00:05:00,840 to scaffold and make sure that everything got processed without any errors. 67 00:05:00,840 --> 00:05:06,980 So for me personally I don't have to create very quickly a new ticket but the idea and make my update 68 00:05:07,150 --> 00:05:11,490 and I'll make a second update just so it's similar to what you're doing now I should have to update 69 00:05:11,510 --> 00:05:16,100 that I've been processed successfully I go back over the scaffold I will see down here. 70 00:05:16,130 --> 00:05:16,730 Fantastic. 71 00:05:16,730 --> 00:05:23,810 I got a message received to get created and then a ticket updated and a ticket updated and very critically 72 00:05:23,810 --> 00:05:27,600 I don't see any errors which means everything still works as expected. 73 00:05:27,600 --> 00:05:30,070 Well all right. 74 00:05:30,150 --> 00:05:33,750 Well this is definitely good improvement it's something that I think will probably carry through to 75 00:05:33,840 --> 00:05:38,670 other scenarios where we need to select a record by its version as well so take a pause right here if 76 00:05:38,670 --> 00:05:42,210 there's one other thing I want to mention around this implementation in just a moment.