1
00:00:01,200 --> 00:00:04,380
Are events now include version numbers which is fantastic.

2
00:00:04,380 --> 00:00:06,020
So we're now going to move over to our orders.

3
00:00:06,030 --> 00:00:08,310
Service inside of our order service.

4
00:00:08,310 --> 00:00:10,770
We will eventually wire up that update.

5
00:00:10,770 --> 00:00:16,320
If current plug in inside of our order model but right now we're going to focus on making our ticket

6
00:00:16,320 --> 00:00:17,520
work correctly.

7
00:00:17,520 --> 00:00:22,490
So I want to make sure that we wire up that plug in to the ticket model inside of orders.

8
00:00:22,590 --> 00:00:26,730
And I want to make sure that we execute all the appropriate logic inside of the ticket.

9
00:00:26,730 --> 00:00:28,060
Updated listener.

10
00:00:28,140 --> 00:00:32,730
So in other words I want to go through the process that we've described many times where we receive

11
00:00:32,730 --> 00:00:38,490
some kind of event and then we run some kind of query to try to find a ticket with the same I.D. and

12
00:00:38,490 --> 00:00:39,960
the version minus one.

13
00:00:39,960 --> 00:00:44,700
So in this case version of to subtract one that gives us one and we would be looking for this version

14
00:00:44,760 --> 00:00:45,770
right here.

15
00:00:45,780 --> 00:00:50,850
We would then apply our updates to this record and when we save it we would want to see that version

16
00:00:50,850 --> 00:00:53,180
number automatically incremented for us.

17
00:00:53,220 --> 00:00:54,690
So that is what we're focused on right now.

18
00:00:54,720 --> 00:01:00,570
We want to make sure the ticket updated events get wired up properly so to get started we're going to

19
00:01:00,570 --> 00:01:06,460
first install that plugin into our order service and we're going to do that at the terminal so at my

20
00:01:06,460 --> 00:01:16,280
terminal I'm inside of my orders service directory and I'll do an npm install Mongoose updates if current

21
00:01:19,920 --> 00:01:20,170
count.

22
00:01:20,180 --> 00:01:22,640
So it's pretty small should install it rather quickly.

23
00:01:22,670 --> 00:01:23,870
Yeah looks good.

24
00:01:24,400 --> 00:01:27,980
So now go back over to my ticket model file inside the orders.

25
00:01:28,020 --> 00:01:30,190
Service is the order service.

26
00:01:30,190 --> 00:01:35,320
I'll find the ticket model file and we're going to wire up the same series of steps so we've done it

27
00:01:35,320 --> 00:01:38,370
back inside the ticket file inside of our ticket service.

28
00:01:38,470 --> 00:01:40,430
We're going to import the plug at the top.

29
00:01:40,510 --> 00:01:47,220
Wired up to the schema analysts this new version property inside of our ticket dock interface so at

30
00:01:47,220 --> 00:01:55,180
the very top we will begin by importing update if current plugin from Mongoose update.

31
00:01:55,270 --> 00:02:04,030
If current all then go down to my schema so here's ticket schema right after it we'll put in ticket

32
00:02:04,030 --> 00:02:12,490
schema set version key and version and then ticket schema plugin update.

33
00:02:12,620 --> 00:02:16,200
If current plugin like so

34
00:02:19,080 --> 00:02:26,360
then finally up inside of our Ticket Talk interface we'll add in the version property again.

35
00:02:26,380 --> 00:02:30,900
This is just here so we can eventually write out code like ticket dot version without having typescript

36
00:02:30,910 --> 00:02:33,780
complain at us okay.

37
00:02:33,820 --> 00:02:34,320
That is it.

38
00:02:34,330 --> 00:02:38,170
We are now using this plugin with the ticket model inside the order service.

39
00:02:38,170 --> 00:02:41,600
So now we're going to focus on making our listener work correctly.

40
00:02:41,630 --> 00:02:46,900
We're gonna make sure that the ticket updated listener is going to receive these events it's going to

41
00:02:46,900 --> 00:02:53,260
reach into the database and try to find a record with DCC Q and whatever the events version is minus

42
00:02:53,260 --> 00:02:53,560
one.

43
00:02:53,800 --> 00:02:57,050
So in this case we'd be looking for a version of one inside the database.

44
00:02:57,160 --> 00:03:01,720
If we do not find some ticket we would throw an error and say hey something's wrong here we were not

45
00:03:01,750 --> 00:03:03,220
able to find the appropriate ticket

46
00:03:06,030 --> 00:03:09,600
so inside of our events listeners directory I'm gonna find a ticket.

47
00:03:09,600 --> 00:03:10,590
Updated listener

48
00:03:14,790 --> 00:03:19,170
we're then going to take a look at the query that we execute right here and we're going to adjust that

49
00:03:19,170 --> 00:03:24,000
query so we're gonna make sure that the query we are on is what we just described find the ticket with

50
00:03:24,050 --> 00:03:31,430
IDC Q and the appropriate version so I'm going to remove the find by I.D. we can't use that query or

51
00:03:31,430 --> 00:03:35,180
that will help her to make the query anymore because now we want to make a query based on two different

52
00:03:35,180 --> 00:03:42,080
criteria both the I.D. and the version number they're gonna change us to a find one.

53
00:03:42,310 --> 00:03:46,580
Well then put in an object and list the filter or search criteria inside of here.

54
00:03:46,600 --> 00:03:48,750
So you want to find a ticket with an I.D..

55
00:03:48,760 --> 00:03:51,470
Notice how it's underscore I.D. of data.

56
00:03:51,600 --> 00:03:52,000
I.D..

57
00:03:53,010 --> 00:03:56,250
And a version of data dot version minus one.

58
00:03:59,880 --> 00:04:04,740
If we mouse over ticket updated event right here or do a command click on it we should see that this

59
00:04:04,740 --> 00:04:06,230
thing now has the version property.

60
00:04:06,270 --> 00:04:10,740
If you do not see that you'll want to restart your code Ed because remember we did just update that

61
00:04:10,740 --> 00:04:17,840
common module so that's where we are getting diversion from is contained inside the event now OK so

62
00:04:17,840 --> 00:04:23,120
we're gonna run that query and again for the 20th time inside this course if we do not find that ticket

63
00:04:23,120 --> 00:04:26,900
right there it means we must be processing events out of order.

64
00:04:26,900 --> 00:04:30,580
And so an example of that would be if we are on Version 3 too early.

65
00:04:30,740 --> 00:04:34,970
We would take version 3 subtract one that would give us version 2 and there's no record inside of our

66
00:04:34,970 --> 00:04:36,320
database with the appropriate version.

67
00:04:36,320 --> 00:04:40,070
So whoops we won't find the ticket and we would end up during an era.

68
00:04:40,070 --> 00:04:45,390
Here's something it says ticket not found and that's pretty much it.

69
00:04:45,400 --> 00:04:48,210
So now we can make our updates to the ticket.

70
00:04:48,220 --> 00:04:51,620
We can set the new type title in price on there and then save the record.

71
00:04:51,620 --> 00:04:56,050
And once we say that record that is why we just wired up this update.

72
00:04:56,050 --> 00:04:58,980
If current plug in to the ticket model inside the order service.

73
00:04:58,990 --> 00:05:03,820
So when we say this thing it's going to increment the version to match the version that just came in

74
00:05:03,820 --> 00:05:07,810
the event.

75
00:05:07,870 --> 00:05:08,890
That's pretty much it.

76
00:05:08,920 --> 00:05:12,390
Let's save the thing and then to test it.

77
00:05:12,400 --> 00:05:14,560
We're going to use postman with postman.

78
00:05:14,560 --> 00:05:17,840
We're going to manually create a ticket and then tried to update it.

79
00:05:17,860 --> 00:05:21,580
We're just gonna make sure that all of our code right now runs without any kind of error.

80
00:05:21,580 --> 00:05:25,410
We don't really have anything to verify and say that it's handling concurrency correctly right here

81
00:05:25,720 --> 00:05:29,170
but we'll take a look at an example of how it's going to fix that stuff in just a little bit.

82
00:05:30,210 --> 00:05:30,400
Yeah.

83
00:05:30,430 --> 00:05:31,300
So inside of postman

84
00:05:35,760 --> 00:05:40,940
I'm going to first go to my tab where I am making a post request to API slash tickets.

85
00:05:40,940 --> 00:05:45,050
I am of course going to make sure I'm authenticated really quickly as well so API users current user

86
00:05:45,110 --> 00:05:51,170
yep I'm authenticated so post requests to API slash tickets and I'll put in a title a price I'm going

87
00:05:51,170 --> 00:05:52,160
to send that off.

88
00:05:52,430 --> 00:05:54,110
And here is my created ticket.

89
00:05:54,380 --> 00:05:59,570
If I go over to scaffold really quickly I should see some event saying something around hey we have

90
00:05:59,570 --> 00:06:02,630
published this event and receive the event as well.

91
00:06:02,630 --> 00:06:03,860
So if you take a look at scaffold.

92
00:06:03,860 --> 00:06:04,740
Really quick.

93
00:06:04,770 --> 00:06:04,960
Yeah.

94
00:06:04,970 --> 00:06:05,630
There we go.

95
00:06:05,640 --> 00:06:10,850
Publish ticket created and received ticket created.

96
00:06:10,860 --> 00:06:15,660
So now take the idea the ticket that I just made and I'm going to try to make an update to this ticket

97
00:06:16,740 --> 00:06:18,790
so I'll go over to my put request tab

98
00:06:21,870 --> 00:06:23,340
over on this put request tab.

99
00:06:23,340 --> 00:06:28,110
I'll make sure that I am making a put request to API slash tickets and then going to put in the idea

100
00:06:28,110 --> 00:06:30,300
of the record that we just created a moment ago.

101
00:06:30,300 --> 00:06:32,960
So remember we can get that from the post request tab.

102
00:06:33,270 --> 00:06:35,350
That idea right there.

103
00:06:35,460 --> 00:06:37,720
I got through it at the very end of the URL.

104
00:06:37,730 --> 00:06:42,400
I'll then make sure that there is some new price listed in here then finally I'm going to send this

105
00:06:42,410 --> 00:06:44,200
off.

106
00:06:44,250 --> 00:06:46,670
Let's go back over to scaffold and see how we're doing.

107
00:06:46,710 --> 00:06:52,130
So it looks like I was able to successfully process the created and the updates as well.

108
00:06:52,290 --> 00:06:58,020
And in theory this should now solve a lot of these different concurrency issues but it's kind of hard

109
00:06:58,020 --> 00:07:01,100
to see that from the limited style of testing we have right now.

110
00:07:01,270 --> 00:07:02,240
And take a quick pause.

111
00:07:02,250 --> 00:07:05,610
We're gonna come back the next video and we're going to try to run that little test script I put together

112
00:07:05,610 --> 00:07:10,890
again and see if there's still any disagreement between the records on our order service and the ticket

113
00:07:10,890 --> 00:07:11,870
service.

114
00:07:11,910 --> 00:07:13,440
Let's take a look at that in just a moment.