1
00:00:01,110 --> 00:00:02,930
This is going to be a optional video.

2
00:00:02,940 --> 00:00:03,810
Hundred percent optional.

3
00:00:03,810 --> 00:00:05,990
So if you just want stay focused on the topic at hand.

4
00:00:06,040 --> 00:00:08,020
Plus a video right now and continue on.

5
00:00:08,040 --> 00:00:11,490
Otherwise stick around and I'll tell you what we're going to discuss in this video.

6
00:00:11,490 --> 00:00:16,380
So I want you to notice how between our ticket service and the order service we use that exact same

7
00:00:16,380 --> 00:00:19,040
module to manage all that versioning stuff.

8
00:00:19,140 --> 00:00:25,890
So we made use in both services of that module called Mongoose update if current.

9
00:00:25,890 --> 00:00:28,600
Now to be honest with you that was kind of cheating.

10
00:00:28,620 --> 00:00:33,290
We are kind of cheating by using this module inside of both these different services.

11
00:00:33,300 --> 00:00:34,500
Let me tell you why.

12
00:00:34,830 --> 00:00:40,950
By using this service or that module we are able to assume that this order is database right here in

13
00:00:40,950 --> 00:00:44,640
all the tickets inside of it are essentially going to manage themselves.

14
00:00:44,640 --> 00:00:50,250
So in other words whenever we have some incoming event come in we're going to go through that process

15
00:00:50,250 --> 00:00:53,460
of subtracting the version number to find the appropriate record.

16
00:00:53,460 --> 00:00:59,520
We then apply some updates that record and then specifically a real gotcha here is that this module

17
00:00:59,970 --> 00:01:04,710
when we save the updated ticket it is going to take the version number right here already inside of

18
00:01:04,710 --> 00:01:07,670
our database and incremented by 1.

19
00:01:07,740 --> 00:01:12,660
So that module alone is responsible for updating the version number inside of our orders database right

20
00:01:12,690 --> 00:01:13,660
now.

21
00:01:13,740 --> 00:01:15,000
Is that a bad thing.

22
00:01:15,000 --> 00:01:17,010
Well I would argue yes it is.

23
00:01:17,010 --> 00:01:21,480
And here's why right now we are 100 percent aware of where these events are coming from.

24
00:01:21,480 --> 00:01:25,920
We know they're coming from the ticket service and we know exactly how the version numbers work inside

25
00:01:25,920 --> 00:01:27,140
that ticket service.

26
00:01:27,150 --> 00:01:31,750
We know that they start off at zero and they are incremented by 1 every single time.

27
00:01:31,800 --> 00:01:38,130
So we are able to make use of the Mongoose update if current module inside the order service just because

28
00:01:38,130 --> 00:01:42,960
it matches the exact same versioning semantics as the ticket service.

29
00:01:42,960 --> 00:01:48,030
But there might be some kind of scenario out there at some future point in time where these ticket updated

30
00:01:48,060 --> 00:01:51,750
events are coming from a totally different kind of database.

31
00:01:51,750 --> 00:01:56,340
Maybe it's not a mongo database maybe it's something that doesn't use Mongoose might be a totally different

32
00:01:56,340 --> 00:02:01,920
kind of information stored and with these other kinds of information stores we cannot necessarily always

33
00:02:01,920 --> 00:02:09,300
rely on them using the exact same versioning semantics as this Mongo Mongoose update if current module

34
00:02:10,720 --> 00:02:16,470
so inside of some alternate universe we might have these events coming in from some other part of our

35
00:02:16,470 --> 00:02:17,000
application.

36
00:02:17,010 --> 00:02:20,960
We don't really know and they still might look identical so there's still ticket created.

37
00:02:20,960 --> 00:02:26,250
Ticket updated tick up tick it updated but they might have an entirely different schema for applying

38
00:02:26,250 --> 00:02:30,990
versioning numbers so they might start off with a version number of one hundred and then increment by

39
00:02:31,130 --> 00:02:33,730
one hundred for every successive version.

40
00:02:33,730 --> 00:02:38,730
And if that was the case we could definitely not make use of this very easy to use module inside of

41
00:02:38,730 --> 00:02:44,100
our order service because it is always assuming though our versioning starts off at 0 and increments

42
00:02:44,160 --> 00:02:51,310
by 1 every single time it update is issued besides having this very different kind of versioning where

43
00:02:51,310 --> 00:02:57,010
we start off at 100 in and increment by 100 every single time there might be some other database that's

44
00:02:57,040 --> 00:03:00,610
emitting these events or some other service that's limiting these events and they might use a version

45
00:03:00,610 --> 00:03:07,110
that has a timestamp to indicate when this record was St. And so once again maybe that time stamp doesn't

46
00:03:07,110 --> 00:03:12,240
work too well with the Mongoose plugin we are using among these plugin we are using does technically

47
00:03:12,540 --> 00:03:18,210
support timestamps Well it's imagined for whatever reason these timestamps are not interoperable for

48
00:03:18,210 --> 00:03:18,810
some reason.

49
00:03:18,810 --> 00:03:19,320
Who knows.

50
00:03:19,320 --> 00:03:19,800
I don't know.

51
00:03:19,920 --> 00:03:24,270
The point here is that we are kind of cheating by allowing all these version numbers inside the orders

52
00:03:24,270 --> 00:03:27,090
database to just be managed by that plugin.

53
00:03:27,660 --> 00:03:33,630
So the goal of this video what I want to do I want to try to remove that plugin from the orders service

54
00:03:33,780 --> 00:03:37,890
and I want to show you how we could implement all the same versioning kind of stuff and manage the version

55
00:03:37,890 --> 00:03:43,950
numbers increment the version numbers on our own rather than relying upon the module that we installed.

56
00:03:43,950 --> 00:03:45,270
That's the goal of this video.

57
00:03:45,300 --> 00:03:46,610
So if that doesn't sound interesting.

58
00:03:46,650 --> 00:03:47,250
No problem.

59
00:03:47,250 --> 00:03:49,220
Just pause video skip on ahead.

60
00:03:49,350 --> 00:03:53,060
Just you know we are going to revert all the changes we're going to make in this video.

61
00:03:53,070 --> 00:03:58,170
So this is solely for informational purposes just to understand that we are not really tightly coupled

62
00:03:58,170 --> 00:04:01,290
to this burgeoning module that we just installed.

63
00:04:01,320 --> 00:04:07,980
So don't mind the first thing we have to do to somehow replace this plugin is understand what it actually

64
00:04:07,980 --> 00:04:09,040
does.

65
00:04:09,060 --> 00:04:12,180
So there's really two primary goals of that plug in right now.

66
00:04:12,270 --> 00:04:17,970
Here's what it really does so it's going to update the version number by one on records before they

67
00:04:17,970 --> 00:04:18,960
get saved.

68
00:04:18,960 --> 00:04:22,340
That's step number one as the first thing it does.

69
00:04:22,360 --> 00:04:26,960
The second thing that it really does is it customize as the find and update operation.

70
00:04:26,980 --> 00:04:31,340
So remember that's when we actually save a record when we save a record.

71
00:04:31,480 --> 00:04:36,310
Mongoose is going to make that request ever to mongo and it's going to say not only try to find some

72
00:04:36,310 --> 00:04:40,930
record with this idea and update it this module is also going to modify that query and change it into

73
00:04:40,990 --> 00:04:47,200
find a record with this I.D. And this particular version number and update it does the two things that

74
00:04:47,200 --> 00:04:49,290
this module is really doing for us.

75
00:04:49,300 --> 00:04:52,150
So these are the two behaviors that we need to somehow replace.

76
00:04:52,150 --> 00:04:55,680
So to speak we're going to first focus on step number one.

77
00:04:55,680 --> 00:05:00,330
How are we going to somehow make sure that this version number can somehow get updated or whatever it

78
00:05:00,330 --> 00:05:03,270
is without having to rely on this module.

79
00:05:03,270 --> 00:05:05,930
Well for that I'm gonna go backwards.

80
00:05:05,940 --> 00:05:12,460
My listener so inside the listener at some point time we take some information out of this incoming

81
00:05:12,460 --> 00:05:15,480
event set it on our ticket and then save it.

82
00:05:15,700 --> 00:05:22,060
There is technically another piece of information on this data object the version property to the version

83
00:05:22,120 --> 00:05:26,860
that is contained inside that event is what we want to update our local ticket to have.

84
00:05:26,860 --> 00:05:31,810
Remember that was super key and all these flow diagrams so we went through back over here every single

85
00:05:31,810 --> 00:05:36,700
time we had said that we were going to say process this event we were going to find the appropriate

86
00:05:36,700 --> 00:05:40,750
record inside the database by taking that version right there subtracting one and finding the appropriate

87
00:05:40,750 --> 00:05:43,460
record we would find this record right here.

88
00:05:43,570 --> 00:05:49,510
We would then update the price and then update the version on this thing to really not just incremented

89
00:05:49,510 --> 00:05:56,120
by 1 but really what we're doing here is incrementing it to be equal to the version inside of this event.

90
00:05:56,170 --> 00:06:00,490
And so right now we are able to rely upon that plugin because it's going to increment by one for us

91
00:06:00,490 --> 00:06:02,720
automatically which is really what we want.

92
00:06:02,800 --> 00:06:06,470
But again what if this was a totally discontinuous version no.

93
00:06:06,580 --> 00:06:09,070
What if it was incremented by 100 or something like that.

94
00:06:09,070 --> 00:06:13,720
Well then we would have to somehow jump in and extract that version number and assign it to our record

95
00:06:13,750 --> 00:06:20,620
inside the database so we would take three not just because we are taking two plus one but we would

96
00:06:20,650 --> 00:06:27,340
assign version three specifically because that is what is inside this event right here so how we can

97
00:06:27,340 --> 00:06:33,370
reflect that inside of our code when we pull off some data from some information from that data object

98
00:06:33,460 --> 00:06:36,160
and then set it on our document and save it.

99
00:06:36,160 --> 00:06:41,760
We could also just pull off the version assign it to our document and that's it.

100
00:06:42,950 --> 00:06:46,760
So this now achieves the exact same thing that that plugin was doing for us.

101
00:06:46,760 --> 00:06:51,320
But now we are no longer coupled to this plugins understanding of how these virgin numbers increment.

102
00:06:51,350 --> 00:06:56,400
Instead we are using the precise version that was included inside of this data object.

103
00:06:56,420 --> 00:07:03,020
So now inside that data object we could potentially have version numbers like this right here where

104
00:07:03,020 --> 00:07:07,250
they are incremented by one hundred every single time or we could potentially have timestamps.

105
00:07:07,250 --> 00:07:11,510
It really doesn't matter we're just saying take whatever this new version number is inside this event

106
00:07:11,570 --> 00:07:17,210
assign it to our record and save it because now that is the current version that kind of solves step

107
00:07:17,210 --> 00:07:18,260
number one right here.

108
00:07:18,320 --> 00:07:23,180
As easy as that was we're just copying over that one property and that kind of handles this idea of

109
00:07:23,210 --> 00:07:25,100
updating that version number.

110
00:07:25,190 --> 00:07:30,110
Now step number two we need to make sure that when we reach into our database to save this record we

111
00:07:30,110 --> 00:07:33,890
need to somehow customize the query that is used.

112
00:07:33,920 --> 00:07:37,380
So this is where life gets just a little bit more challenging.

113
00:07:37,400 --> 00:07:42,740
I want to first show you some documentation over on Mongoose on how we can essentially inject something

114
00:07:42,740 --> 00:07:45,170
to customize this update operation.

115
00:07:45,170 --> 00:07:48,320
Now just you know the Mongoose documentation is not the best in the world.

116
00:07:48,320 --> 00:07:53,120
In addition the typescript type definition file that we are using is also not really gonna show us some

117
00:07:53,120 --> 00:07:54,440
information about this feature.

118
00:07:54,490 --> 00:07:58,850
I'm going to show you as well though this is where we're going to get a little bit hacky so to speak

119
00:07:58,880 --> 00:08:00,280
just so you know.

120
00:08:00,280 --> 00:08:06,440
So if you take a look at the Mongoose documentation we can see that on the model class there is technically

121
00:08:06,470 --> 00:08:12,560
a dollar sign where property and we can modify this dollar sign where property and this will attach

122
00:08:12,560 --> 00:08:18,260
some additional properties to the query that is executed when calling save and win is new is false.

123
00:08:18,260 --> 00:08:24,050
So in other words long story short this does exactly what that module does or what this update if current

124
00:08:24,050 --> 00:08:30,290
plugin does this can allow us to kind of inject some additional criteria on the query that is issued

125
00:08:30,290 --> 00:08:32,040
when we tried to update a record.

126
00:08:32,060 --> 00:08:36,950
So this is where we can add in some additional step and say hey we don't only want to find the record

127
00:08:36,950 --> 00:08:41,090
with the correct I.D. We also want to find some correct record with the correct version and then update

128
00:08:41,120 --> 00:08:42,590
that record.

129
00:08:42,590 --> 00:08:47,090
So this property right here is essentially how we would kind of override or add in some additional query

130
00:08:47,090 --> 00:08:49,110
properties.

131
00:08:49,110 --> 00:08:53,100
Now the reason I mentioned that the documentation is not great here that the type definition file is

132
00:08:53,100 --> 00:08:56,640
not great is that understanding how to actually set this thing is a little bit challenging.

133
00:08:56,640 --> 00:08:59,440
So again this is where life is going to get just a little bit hacky.

134
00:08:59,460 --> 00:09:02,770
But let's just write out the code and see where it goes.

135
00:09:02,820 --> 00:09:06,630
So back inside of my ticket model definition file.

136
00:09:06,630 --> 00:09:08,870
So this again is inside the order service.

137
00:09:08,900 --> 00:09:13,300
So inside order service models ticket T.S. I'm going to scroll down

138
00:09:16,280 --> 00:09:21,300
to right after we set our ticket schema and the plugin while I'm here.

139
00:09:21,300 --> 00:09:24,560
I'm going to comment out the plugins that we're not using this thing at all anymore.

140
00:09:24,570 --> 00:09:26,290
So now we're kind of on our own right.

141
00:09:26,340 --> 00:09:30,690
We have to make sure that whenever we tried to write some records to the database we are writing to

142
00:09:30,690 --> 00:09:36,020
the correct record or the record with the right ideas and the right version so right after that we're

143
00:09:36,020 --> 00:09:39,360
gonna set up a pre save book

144
00:09:42,440 --> 00:09:44,620
re not preview.

145
00:09:44,630 --> 00:09:50,660
So this is a middleware that's going to run any time that we try to save a record.

146
00:09:50,770 --> 00:09:54,610
We're gonna make sure that we provide a function with the function keyword because like many other Middleware

147
00:09:54,610 --> 00:09:58,690
is in Mongoose the value of the document that we're trying to save is available inside this function

148
00:09:58,720 --> 00:10:00,100
as this.

149
00:10:00,100 --> 00:10:04,150
And if we used an arrow function here that would override the value of this inside the function and

150
00:10:04,150 --> 00:10:06,310
all the sudden things would not work as expected.

151
00:10:06,310 --> 00:10:11,880
We must make use of the function keyword also remember that this function is going to receive a single

152
00:10:11,880 --> 00:10:12,980
argument of done.

153
00:10:12,990 --> 00:10:15,270
This is a callback function that we have to manually invoke.

154
00:10:15,330 --> 00:10:19,130
Once we've done everything we intend to do inside of this this middleware.

155
00:10:19,130 --> 00:10:20,830
Oh my apologies there.

156
00:10:20,880 --> 00:10:26,950
Back over here so inside of your reach are going to dynamically you're kind of on the fly a reassign

157
00:10:27,010 --> 00:10:32,740
that dollar sign we're property we're going to put in some additional criteria on the Save operation

158
00:10:32,770 --> 00:10:38,470
in how mongoose is going to find the record to actually overwrite or update inside of Mongo DB.

159
00:10:38,520 --> 00:10:48,660
We're gonna say this dot dollar sign where is going to be an object we're gonna set version equal to

160
00:10:48,810 --> 00:10:52,800
whatever the current version is minus one.

161
00:10:52,800 --> 00:11:01,260
So we'll say this dot get version minus one and then right after that I'm going to call done and you're

162
00:11:01,260 --> 00:11:05,220
going to notice that we get an error right here on dollar sign where if I mouse over it's going to say

163
00:11:05,220 --> 00:11:07,970
that a document does not have a dollar sign where property.

164
00:11:07,990 --> 00:11:11,610
This is where the typescript type definition file for Mongoose falls a little bit short.

165
00:11:11,640 --> 00:11:13,770
It doesn't understand that this property exists.

166
00:11:13,800 --> 00:11:16,410
So this is something is kind of erroneous on typescript side.

167
00:11:16,470 --> 00:11:18,600
Let's just doesn't quite understand what's going on here.

168
00:11:18,600 --> 00:11:22,980
So this is another scenario we're going to tell typescript hey just don't sweat it we know what we're

169
00:11:22,980 --> 00:11:24,030
doing here.

170
00:11:24,130 --> 00:11:29,250
We're gonna put it in a T.S. ignore like so just to get that air to go away.

171
00:11:29,460 --> 00:11:30,270
So what is this going to do.

172
00:11:30,300 --> 00:11:33,780
Well it's gonna do the exact same thing that we saw in many of these different diagrams when we reach

173
00:11:33,780 --> 00:11:36,510
out to mongo DB to save this record.

174
00:11:36,510 --> 00:11:41,790
We're not only going say it try to find a record with some appropriate I.D. but also a version equal

175
00:11:41,790 --> 00:11:44,320
to the current version minus one.

176
00:11:44,390 --> 00:11:47,220
Now the minus one right here once again makes a really big assumption.

177
00:11:47,220 --> 00:11:51,210
It assumes that we are incrementing all these version numbers by one every single time.

178
00:11:51,210 --> 00:11:58,150
So if you were in a scenario where the version numbers were say being invented by one hundred.

179
00:11:58,330 --> 00:12:02,830
This is where to find the previous version the one that we are trying to reach into our database and

180
00:12:02,830 --> 00:12:03,460
update.

181
00:12:03,460 --> 00:12:08,350
This is where we would change this minus 1 to minus 100 or whatever else.

182
00:12:08,350 --> 00:12:12,220
So this function right here is pretty much where we get the ability to kind of modify how the version

183
00:12:12,220 --> 00:12:17,000
is being changed over time but in this case we actually are incrementing the version number by one.

184
00:12:17,000 --> 00:12:22,230
So we would put in simply at minus one right here and believe it or not that is it.

185
00:12:22,290 --> 00:12:26,400
We now do not need that plugin anymore now to test this out.

186
00:12:26,420 --> 00:12:30,520
I'm going to say this file and I'm going to save the listener and then we're going to attempt to create

187
00:12:30,550 --> 00:12:35,650
a new ticket and then we'll update it once or twice and we're going to see it that well everything still

188
00:12:35,650 --> 00:12:39,820
works as expected so I'm going to go backward a postman

189
00:12:44,000 --> 00:12:49,050
every go in postman I'm going to create yet another ticket so I got my post up here to API such tickets

190
00:12:49,840 --> 00:12:55,550
to ticket created I'll then take the idea that ticket was just created go to my put tab so making it

191
00:12:55,550 --> 00:13:01,140
put request to API tickets and I'll paste in my I.D. for the ticket I just made and then I'll update

192
00:13:01,140 --> 00:13:06,720
the price on this one to five hundred I'm going send that off I'm going to go over to my terminal scaffold

193
00:13:06,780 --> 00:13:11,640
once again and just make sure that I don't get any errors so it looks like everything's still worked

194
00:13:11,670 --> 00:13:17,490
as expected that version query is still working even though we're not using that plugin and if I wanted

195
00:13:17,490 --> 00:13:23,160
to I can make yet another price change right here let's say go to 2000 send that off.

196
00:13:23,160 --> 00:13:24,820
Go back and read scaffold.

197
00:13:24,850 --> 00:13:27,330
Yeah looks like it still works as well.

198
00:13:27,330 --> 00:13:30,270
And we no longer have any reliance upon that outside module.

199
00:13:30,270 --> 00:13:35,670
And so like I said we can update all these version numbers on the fly to fit the schema of version numbers

200
00:13:35,700 --> 00:13:39,960
being used by this outside service which we might not actually have control over.

201
00:13:39,960 --> 00:13:44,250
Now last thing on you mentioned here is that although I am not receiving any errors you still might

202
00:13:44,250 --> 00:13:49,500
not believe that all the data is being saved correctly so as a last little step let's figure out how

203
00:13:49,500 --> 00:13:52,800
to reach directly into our orders Service database.

204
00:13:52,800 --> 00:13:56,130
We're gonna figure out how to reach directly in there take a look at the tickets collection and just

205
00:13:56,130 --> 00:14:02,580
make sure that these this ticket is being saved with the appropriate I.D. so to reach into the orders

206
00:14:02,640 --> 00:14:05,720
service and look at some information inside of it.

207
00:14:05,850 --> 00:14:09,390
We're going to open up a new tab inside of our terminal.

208
00:14:09,510 --> 00:14:16,170
We're gonna do a cube CTF get pods and we're gonna find a pot that is running our orders Mongo D.B.

209
00:14:16,350 --> 00:14:22,050
instance to mine yours is gonna be named very soon to mine all the orders Mongo devil and then some

210
00:14:22,110 --> 00:14:30,130
long idea after it we're gonna copy that name and it will execute keep Seitel dash I.T. then the pod

211
00:14:30,130 --> 00:14:33,190
name and then Mongo at the very end.

212
00:14:33,520 --> 00:14:38,290
So this is going to execute the command Mongo inside the container inside this pod and that is what

213
00:14:38,290 --> 00:14:42,070
it's going to open up the Mongo shell where we can then start to run some queries directly against the

214
00:14:42,070 --> 00:14:50,390
Mongo DB database and I misspelled cube CTO excuse me I missed the actual command inside of here that

215
00:14:50,390 --> 00:14:54,790
was my mistake UCL I.T. exact or exact I.T..

216
00:14:54,800 --> 00:14:56,270
There you go.

217
00:14:56,270 --> 00:15:01,530
Then the name then Mongo by mistake.

218
00:15:01,530 --> 00:15:01,980
That's better.

219
00:15:03,120 --> 00:15:07,470
So once I run that I now have my Mongo shell and I could start to run some commands against my Mongo

220
00:15:07,470 --> 00:15:08,750
database.

221
00:15:08,760 --> 00:15:11,880
Now we are gonna have to do one or two little administrative commands inside of here.

222
00:15:11,880 --> 00:15:16,180
We're going to first list all the Ds that exist inside this database.

223
00:15:16,410 --> 00:15:17,720
So there's our orders database.

224
00:15:17,730 --> 00:15:20,560
That's what we want to actually connect to and run some queries inside of.

225
00:15:21,110 --> 00:15:30,340
So we'll write out use orders and now we can write out DV tickets and that will access the tickets collection

226
00:15:30,340 --> 00:15:32,270
inside the orders database.

227
00:15:32,320 --> 00:15:35,960
So again the entire idea here is I want to try to find the ticket.

228
00:15:36,220 --> 00:15:40,360
We had just created a moment ago and updated twice and just make sure that it has the appropriate versus

229
00:15:40,360 --> 00:15:46,730
no price and so on make sure all the stuff is actually being saved correctly so to do so I could run

230
00:15:46,780 --> 00:15:54,990
DV dot tickets dot find and I'm going to try to find a ticket with a price equal to whatever you had

231
00:15:55,020 --> 00:15:56,540
last set inside of here.

232
00:15:56,550 --> 00:15:58,020
So for me it's a price of two thousand

233
00:16:01,310 --> 00:16:05,120
I'll run that and then I'll see all the tickets that match that particular price.

234
00:16:05,120 --> 00:16:08,420
If you get too many records right here just make one more update to your ticket.

235
00:16:08,450 --> 00:16:09,830
Give it a very unique price.

236
00:16:09,920 --> 00:16:14,810
Maybe something like 1 9 8 two point three.

237
00:16:14,810 --> 00:16:19,760
I don't know then enough that update and now that you've got a much more unique price you can run that

238
00:16:19,760 --> 00:16:26,400
query again with 1 9 8 two point three so we'll see.

239
00:16:26,440 --> 00:16:29,470
Now inside of here that we've got the aversion all set up correctly.

240
00:16:29,580 --> 00:16:34,600
It has been incremented by 1 every single time and well it's got the exact same functionality more or

241
00:16:34,600 --> 00:16:37,840
less as the module that we have been using previously.

242
00:16:37,840 --> 00:16:39,580
The update if current plugin.

243
00:16:39,880 --> 00:16:40,570
That's pretty much it.

244
00:16:40,570 --> 00:16:45,430
That is how we would implement this stuff on our own if we were using some kind of versioning schema

245
00:16:45,700 --> 00:16:48,810
that was not the same as the one that is assumed by this plugin.

246
00:16:48,820 --> 00:16:53,080
Again this is most relevant if you're starting to get some events from some other service that uses

247
00:16:53,110 --> 00:16:58,750
a very different kind of database where maybe maybe it's not even using versions in the hundreds.

248
00:16:58,750 --> 00:17:01,570
I don't know of any database that does anything even remotely like that.

249
00:17:01,930 --> 00:17:07,080
I just wanted to know that this was an option what might be actually kind of relevant or appropriate

250
00:17:07,080 --> 00:17:11,610
is if there's some other versioning system where they don't start at version of zero near the first

251
00:17:11,610 --> 00:17:13,670
version has a version of one instead.

252
00:17:13,710 --> 00:17:18,360
That would have a different schema for versioning than this plug n and potentially things could start

253
00:17:18,360 --> 00:17:19,630
to break.

254
00:17:19,650 --> 00:17:19,940
OK.

255
00:17:19,980 --> 00:17:20,250
So.

256
00:17:20,250 --> 00:17:25,050
Enough talking again this is just kind of optional stuff just for something for you to know on the side.

257
00:17:25,070 --> 00:17:30,180
I am going to undo all the changes we are going to stick with this plug in not the best assumption not

258
00:17:30,180 --> 00:17:30,900
the best thing to use.

259
00:17:30,900 --> 00:17:32,300
Like I said we're kind of cheating here.

260
00:17:32,340 --> 00:17:38,250
Nonetheless I'm going to make use of it nonetheless get I'm going to delete the middleware dice but

261
00:17:38,250 --> 00:17:40,530
together I'm going uncommon the plug in

262
00:17:43,970 --> 00:17:46,900
I don't think there are any other changes we made inside of here.

263
00:17:47,120 --> 00:17:51,770
So I'm going to save this file I'll then go back over to the listener and no longer are we going to

264
00:17:51,770 --> 00:17:57,770
copy that version number over they'll delete where we were pulling version of data and make sure I do

265
00:17:57,770 --> 00:18:03,830
not set it on the ticket anymore looking to save this and I'm going to go and make one last test inside

266
00:18:03,830 --> 00:18:08,690
a post man just make sure everything still works as expected I'll change my price this time to about

267
00:18:09,080 --> 00:18:16,900
1 0 three point three send that off I'm now on to version four and so I'll go run a quick query inside

268
00:18:16,900 --> 00:18:22,590
of Mongo to be at once again one two three point three Yep version four.

269
00:18:22,590 --> 00:18:23,490
Fantastic.

270
00:18:23,490 --> 00:18:27,300
So we just swapped back over to that plugin and everything's still worked as expected.

271
00:18:27,300 --> 00:18:28,530
Pretty awesome.

272
00:18:28,780 --> 00:18:28,920
Yeah.

273
00:18:28,950 --> 00:18:30,450
So again just option a little video.

274
00:18:30,450 --> 00:18:31,080
Hope you enjoyed it.

275
00:18:31,200 --> 00:18:34,140
Let's take a pause right here and continue with our app in just a moment.