1
00:00:00,820 --> 00:00:05,320
In this video we're going to get a better idea of how Mongoose and Mongo DB collaborate to set up and

2
00:00:05,320 --> 00:00:07,600
use this version field stuff.

3
00:00:07,600 --> 00:00:08,080
All right.

4
00:00:08,080 --> 00:00:13,300
First you're going to do is take a look at how it Mongoose and Mongo DB normally collaborate to handle

5
00:00:13,360 --> 00:00:14,650
record updates.

6
00:00:14,650 --> 00:00:17,750
So this is it without this version flag or anything like that.

7
00:00:17,830 --> 00:00:21,920
So inside of our ticket service we might have some code that's going to fetch record season.

8
00:00:21,940 --> 00:00:25,170
Q We might then run some update on a document.

9
00:00:25,180 --> 00:00:29,160
So for example set its price to 10 or 15 or whatever else.

10
00:00:29,200 --> 00:00:35,100
Well then tell Mongoose to save the document and very critically when that occurs mongoose is going

11
00:00:35,100 --> 00:00:40,510
to reach out to Mongo DB and it's going to tell Mongo D.B. hey I want you to do an update on record

12
00:00:40,560 --> 00:00:40,960
season.

13
00:00:40,960 --> 00:00:44,330
Q Does going to send off some kind of request to Mongo DB.

14
00:00:44,530 --> 00:00:50,320
And a very critical part here is that inside this request there's something that says bind the record

15
00:00:50,320 --> 00:00:58,010
with I.T. C.C. Q and satisfies you 10 so Mongo DB internally is going to look at its collection of tickets.

16
00:00:58,070 --> 00:01:03,000
It's gonna find a record with IDC Q And then update its price to 10 and that's it.

17
00:01:03,050 --> 00:01:04,220
That's the entire process.

18
00:01:05,470 --> 00:01:09,730
Now the thing I really want to emphasize here is that in the request to update this record there is

19
00:01:09,730 --> 00:01:13,570
something that says find specifically at the record with Idi Caesar.

20
00:01:13,570 --> 00:01:19,030
Q Okay so if all that mind let's not take a look at the same flow but with all this version tracking

21
00:01:19,030 --> 00:01:24,130
stuff enabled we're going to see how Mongoose and Margaux D we collaborate to make sure that we only

22
00:01:24,160 --> 00:01:29,690
update records with the appropriate version number OK so same kind of flow here.

23
00:01:29,720 --> 00:01:34,880
But now we're imagining that this version Fielding is being incorporated or included and just you know

24
00:01:34,880 --> 00:01:39,140
this entire process that we're going through is referred to as optimistic concurrency control.

25
00:01:39,260 --> 00:01:43,100
And if you want to you could do a quick google search take a look at a blog post or two and read a little

26
00:01:43,100 --> 00:01:44,160
bit more about it.

27
00:01:44,270 --> 00:01:48,680
The entire strategy that we're talking about here for optimistic concurrency control at Mongo DV is

28
00:01:48,770 --> 00:01:52,480
100 percent applicable to other types of databases as well.

29
00:01:52,520 --> 00:01:58,160
So what we're discussing here is not isolated to mongo DV at this is not a mango DB specific strategy

30
00:01:58,400 --> 00:02:03,930
you can use the strategy with many other types of databases very easily OK.

31
00:02:03,960 --> 00:02:08,400
So in this flow we're going to once again fetch a record from Susie Q run update on the documents save

32
00:02:08,400 --> 00:02:13,440
the document and then internally we're going to turn a setting on inside a mongoose that's going to

33
00:02:13,440 --> 00:02:18,430
cause Mongoose to automatically update the version field of the document automatically.

34
00:02:18,510 --> 00:02:22,680
So that would be where we increment the version field from say one to two to three three to four or

35
00:02:22,680 --> 00:02:28,580
whatever else mongoose is then once again going to send an update request off to Mongo DB.

36
00:02:28,740 --> 00:02:34,860
And now now that we are implementing this versioning stuff here is the critical critical difference

37
00:02:35,190 --> 00:02:42,270
inside this request mongoose is going to tell Mongo DV to find the record with IDC Q and A version of

38
00:02:42,270 --> 00:02:44,760
one and set its price to 10.

39
00:02:44,910 --> 00:02:47,110
That is the critical little step.

40
00:02:47,190 --> 00:02:53,010
So whenever Mongo DB it tries to update to record it's not actually going to try to compare these version

41
00:02:53,010 --> 00:02:58,290
numbers and say hey is this less than 1 or is this less than the current first number or whatever else

42
00:02:58,590 --> 00:02:59,580
that doesn't actually occur.

43
00:02:59,580 --> 00:03:05,550
What really happens is mongoose is going to say find the record with this particular I.D. And this particular

44
00:03:05,550 --> 00:03:06,570
version.

45
00:03:06,720 --> 00:03:11,040
So it's in how we find this record that's going to make sure that we select some record with the correct

46
00:03:11,040 --> 00:03:12,520
version.

47
00:03:12,530 --> 00:03:17,100
Now let's imagine the scenario in which we do have a record inside of our database with an idea a Q

48
00:03:17,130 --> 00:03:18,330
and A version of one.

49
00:03:18,560 --> 00:03:20,310
We would find this record right here.

50
00:03:20,360 --> 00:03:25,190
It has the correct I.D. and the correct version and we had set its price to 10 and that's it.

51
00:03:25,220 --> 00:03:27,090
Everyone is happy now.

52
00:03:27,170 --> 00:03:30,440
What would happen if something goes not quite right.

53
00:03:30,440 --> 00:03:31,970
Well I'm going to roll this back.

54
00:03:31,970 --> 00:03:36,680
Now let's imagine that we accidently process the 15 dollar price update first.

55
00:03:36,680 --> 00:03:39,910
So that would have been the event that we discussed just a moment ago.

56
00:03:39,980 --> 00:03:45,290
This one right here where we're trying to set the price to 15 and we would be looking for a record inside

57
00:03:45,350 --> 00:03:52,300
of our database with a version of two because this thing has a version of three so in that scenario

58
00:03:53,110 --> 00:03:58,870
this query right here would instead say find the record with DCC Q and A version of two and set its

59
00:03:58,870 --> 00:04:00,720
price to 15.

60
00:04:00,730 --> 00:04:04,760
Now as you can guess Mongo DB is gonna run a query over the ticket's collection.

61
00:04:04,870 --> 00:04:10,870
It's gonna look for a record with a idea of season Q and A version of two so we can look through all

62
00:04:10,870 --> 00:04:13,890
these records and there's no record that matches that query.

63
00:04:13,890 --> 00:04:16,960
There's no record that an idea sees a Q and A version of two.

64
00:04:16,960 --> 00:04:19,200
There is one with an idea Cizik universe of one.

65
00:04:19,210 --> 00:04:24,780
But that's not what we're asking for we're asking for one with a version specifically of two.

66
00:04:24,880 --> 00:04:29,800
And so this request right here this update would fail and this error would be returned to our application

67
00:04:30,010 --> 00:04:33,580
where we would be forced to deal with it in some fashion but that's it.

68
00:04:33,580 --> 00:04:35,230
That is what is going on behind the scenes.

69
00:04:35,260 --> 00:04:40,270
It's really all hinging upon the fact that when we send over these requests to update record we're including

70
00:04:40,330 --> 00:04:44,920
not only the idea of the record we're trying to update but also the version of the record we're trying

71
00:04:44,920 --> 00:04:45,690
to update as well.

72
00:04:45,730 --> 00:04:50,790
And that is what is used for the criteria to find the record that we're trying to make a change to not

73
00:04:50,920 --> 00:04:53,780
thing you'll notice here is that this is all about updating records.

74
00:04:53,780 --> 00:04:55,940
It's not about inserting records.

75
00:04:56,000 --> 00:04:59,930
So the assumption is that when we first insert a record it's always going to default to a version of

76
00:05:00,140 --> 00:05:02,080
0 or 1.

77
00:05:02,090 --> 00:05:05,080
So we don't really run into a big issues with inserting records.

78
00:05:05,090 --> 00:05:06,550
Not really a big concurrency issue there.

79
00:05:06,560 --> 00:05:10,010
It's a bigger issue when we're trying to update existing records.

80
00:05:10,010 --> 00:05:11,650
That's when we start to get into big trouble.

81
00:05:11,720 --> 00:05:17,040
And that's where this version flag is going to start to become really really handy.

82
00:05:17,090 --> 00:05:17,510
So that's it.

83
00:05:17,510 --> 00:05:18,200
That's the idea.

84
00:05:18,200 --> 00:05:22,250
So as you guess Well we have to make a little change or two to mongoose.

85
00:05:22,310 --> 00:05:25,940
We'll take a quick pause right here in the next video we're going to see how to actually implement this

86
00:05:25,940 --> 00:05:27,020
stuff in the world a mongoose.

87
00:05:27,020 --> 00:05:31,970
We're also going to write out a test or two inside replication so you can actually write some code and

88
00:05:31,970 --> 00:05:35,890
immediately start to work with this version stuff and get a better idea of what's going on with it.