1 00:00:01,830 --> 00:00:05,330 Our test around optimistic and currency control is working as expected. 2 00:00:05,430 --> 00:00:09,750 As I mentioned I would like to write out just one other very small test right now where you don't actually 3 00:00:09,750 --> 00:00:14,990 have anything to prove that whenever we save or update a record the version number actually gets incremented. 4 00:00:15,010 --> 00:00:20,220 So I want to write out just a very quick second test to say that whenever we save a record if we refresh 5 00:00:20,220 --> 00:00:24,600 it that we see that version number get incremented by 1. 6 00:00:24,620 --> 00:00:26,620 So I'm gonna go down to the bar on the file. 7 00:00:26,720 --> 00:00:33,290 I'm gonna write out another statement and we'll say it increments the version number on multiple saves 8 00:00:36,330 --> 00:00:39,340 so then instead of here we're going to once again write a new ticket. 9 00:00:39,340 --> 00:00:40,330 We're going to save it. 10 00:00:40,330 --> 00:00:45,280 We're going to expect that these saved ticket has a version number of zero will then go to save the 11 00:00:45,280 --> 00:00:49,870 thing a second time and a third time and we're going to expect that every single time we save this ticket 12 00:00:50,050 --> 00:00:57,190 the version number automatically gets incremented so I'm going to do a ticket is take it up built or 13 00:00:57,210 --> 00:01:04,960 put in a title of concerts price whatever 20 user I.D. one two three doesn't really matter so then do 14 00:01:04,970 --> 00:01:10,580 and a weight ticket that save right after we say this thing for the very first time we should by default 15 00:01:10,790 --> 00:01:12,830 have a version number equal to zero. 16 00:01:12,890 --> 00:01:14,920 So I'm going to write out an expectation for that. 17 00:01:14,930 --> 00:01:23,520 So expect ticket out version to equal zero and now if I tried to save the same record another time we 18 00:01:23,640 --> 00:01:25,370 don't even have to really make an update here. 19 00:01:25,400 --> 00:01:28,100 You don't have to make an update just any time we save the record. 20 00:01:28,100 --> 00:01:31,260 We expect that that version number gets incremented by 1. 21 00:01:31,280 --> 00:01:38,790 So if I do another weight ticket that save I should now be able to expect that the ticket version husband 22 00:01:38,820 --> 00:01:48,350 incremented to 1 Nashville to do that yet again and expect that the ticket version will have gone up 23 00:01:48,350 --> 00:01:49,400 to 2. 24 00:01:49,430 --> 00:01:52,060 Like so. 25 00:01:52,100 --> 00:01:53,340 So let's say this. 26 00:01:53,670 --> 00:01:55,160 Take a look at our tests. 27 00:01:55,230 --> 00:01:56,920 Looks like that is passing as well. 28 00:01:58,270 --> 00:02:00,570 Once again just make sure that it's working as expected. 29 00:02:00,580 --> 00:02:04,560 Going to change the version number on the very last one on a two equal to one. 30 00:02:04,630 --> 00:02:08,680 I'll save that and yep looks like it's working as expected. 31 00:02:08,710 --> 00:02:09,860 So going to undo that change. 32 00:02:09,880 --> 00:02:13,620 Save it one more time and just make sure these tests are passing awesome. 33 00:02:14,430 --> 00:02:14,680 OK. 34 00:02:14,710 --> 00:02:17,710 So that is the basics of Optimistic concurrency control. 35 00:02:17,710 --> 00:02:21,910 Now the one thing I do want to mention here we have a test that's essentially making sure that if we 36 00:02:21,910 --> 00:02:27,580 start to make changes to a record or the same instance of a record in memory then we try to save these 37 00:02:27,580 --> 00:02:28,620 things all at the same time. 38 00:02:28,630 --> 00:02:31,990 We're gonna make sure that we only process one of those updates. 39 00:02:31,990 --> 00:02:34,620 So this is not necessarily a test. 40 00:02:34,630 --> 00:02:38,980 Identical to what we want to use the stuff for which is to make sure that we are processing events in 41 00:02:38,980 --> 00:02:39,930 the correct order. 42 00:02:39,940 --> 00:02:45,430 It's very similar but it's not quite exactly what we're intending to using to use the Optimistic concurrency 43 00:02:45,430 --> 00:02:46,040 control stuff for. 44 00:02:46,040 --> 00:02:50,320 So at this point in time the only reason I mentioned that if you were looking at this test in St. yourself 45 00:02:50,560 --> 00:02:54,990 Hey Steven how does this simulate US processing events out of order or something like that. 46 00:02:55,030 --> 00:03:01,030 I'm aware it's not exactly the same but all the ideas this idea of making sure that we find the previous 47 00:03:01,030 --> 00:03:04,210 version in the database and process that or save it accordingly. 48 00:03:04,360 --> 00:03:06,820 It's all the same. 49 00:03:06,850 --> 00:03:11,380 So now that we've got this test put together we're now going to go over to our common module. 50 00:03:11,650 --> 00:03:15,430 We're gonna make sure inside of a lot of our different events we're gonna make sure that these events 51 00:03:15,460 --> 00:03:20,800 communicate the version number of the record that we're trying to communicate out to the outside world 52 00:03:20,830 --> 00:03:22,660 or the rest of all of our services. 53 00:03:22,840 --> 00:03:28,060 So we can make that update to our common module will then go over to our orders service and we're going 54 00:03:28,060 --> 00:03:32,740 to implement the same kind of idea of Optimistic concurrency control when we are attempting to process 55 00:03:32,770 --> 00:03:33,570 these events. 56 00:03:33,610 --> 00:03:37,770 And that's where stuff is going to actually get really useful and even more interesting. 57 00:03:37,840 --> 00:03:41,750 I don't about you I find this stuff kind of interesting as it is but even more interesting. 58 00:03:41,830 --> 00:03:45,040 So a quick buzz update that common module in just a moment.