Our test around optimistic and currency control is working as expected.
As I mentioned I would like to write out just one other very small test right now where you don't actually
have anything to prove that whenever we save or update a record the version number actually gets incremented.
So I want to write out just a very quick second test to say that whenever we save a record if we refresh
it that we see that version number get incremented by 1.
So I'm gonna go down to the bar on the file.
I'm gonna write out another statement and we'll say it increments the version number on multiple saves
so then instead of here we're going to once again write a new ticket.
We're going to save it.
We're going to expect that these saved ticket has a version number of zero will then go to save the
thing a second time and a third time and we're going to expect that every single time we save this ticket
the version number automatically gets incremented so I'm going to do a ticket is take it up built or
put in a title of concerts price whatever 20 user I.D. one two three doesn't really matter so then do
and a weight ticket that save right after we say this thing for the very first time we should by default
have a version number equal to zero.
So I'm going to write out an expectation for that.
So expect ticket out version to equal zero and now if I tried to save the same record another time we
don't even have to really make an update here.
You don't have to make an update just any time we save the record.
We expect that that version number gets incremented by 1.
So if I do another weight ticket that save I should now be able to expect that the ticket version husband
incremented to 1 Nashville to do that yet again and expect that the ticket version will have gone up
to 2.
Like so.
So let's say this.
Take a look at our tests.
Looks like that is passing as well.
Once again just make sure that it's working as expected.
Going to change the version number on the very last one on a two equal to one.
I'll save that and yep looks like it's working as expected.
So going to undo that change.
Save it one more time and just make sure these tests are passing awesome.
OK.
So that is the basics of Optimistic concurrency control.
Now the one thing I do want to mention here we have a test that's essentially making sure that if we
start to make changes to a record or the same instance of a record in memory then we try to save these
things all at the same time.
We're gonna make sure that we only process one of those updates.
So this is not necessarily a test.
Identical to what we want to use the stuff for which is to make sure that we are processing events in
the correct order.
It's very similar but it's not quite exactly what we're intending to using to use the Optimistic concurrency
control stuff for.
So at this point in time the only reason I mentioned that if you were looking at this test in St. yourself
Hey Steven how does this simulate US processing events out of order or something like that.
I'm aware it's not exactly the same but all the ideas this idea of making sure that we find the previous
version in the database and process that or save it accordingly.
It's all the same.
So now that we've got this test put together we're now going to go over to our common module.
We're gonna make sure inside of a lot of our different events we're gonna make sure that these events
communicate the version number of the record that we're trying to communicate out to the outside world
or the rest of all of our services.
So we can make that update to our common module will then go over to our orders service and we're going
to implement the same kind of idea of Optimistic concurrency control when we are attempting to process
these events.
And that's where stuff is going to actually get really useful and even more interesting.
I don't about you I find this stuff kind of interesting as it is but even more interesting.
So a quick buzz update that common module in just a moment.