Well we definitely have to accept some of these concurrency issues but as usual I'm still not entirely
happy with our implementation.
I think there are one or two things that we could definitely improve upon.
The first I want to point out inside of our ticket update a listener we've got this really ugly query
here now.
You've got to find one where you have to add in this somewhat complicated set of filters as you can
imagine duplicating this around to a bunch of other listeners in the future with start to get really
tiring really quickly.
Not only is there this kind of mysterious underscore I.D. where we've been trying to stick to this I.D.
convention quite a bit but we also have this data version minus one.
And it's really likely in my opinion that some other engineers are going to look at this minus one at
some point time and say why would we subtract minus one let's dump that and if we did that everything
would start to break.
So putting the minus one in here I don't really like having to break out these two separate properties
of ideal version.
Also not great.
Long story short I think we can do better than this.
So we're going to build a little helper method on our ticket model directly.
This ticket model is going to take in this entire data object right here and then essentially do the
exact same query but we're just going to kind of wrap everything else everything up and hide away these
nasty implementation details such as underscore I.D. and data version minus one so to get started instead
of my order service.
I'll find the models directory ticket dot yes I'll then find my ticket model there's the ticket model
interface to be precise we're going to add in a new method directly to the model itself that's going
to just facilitate us in doing a query for a I.D. plus a version the inside of here inside the ticket
model interface I'm going to add in a new query method we'll call it How about find by event not the
best name really.
Maybe there's a better name.
I don't only want to call it find by I.D. And version because we're not really finding by version we're
doing a find by I.D. and previous version.
And so that would lead us to a name of something like that which is just way too long in my opinion.
It certainly is clear about what's going on but I don't know I'm going to just stick with find by events
and the assumption here is I'm going to pass in some kind of event or data object.
This method will pull off the I.D. And version properties subtract one from the version and use that
to run the same query we had wrote written just a moment ago so let's say that this is going to receive
some kind of event ish object and I'll just put a type of notation for it right here directly in line.
I'll say that whatever we pass in must have an I.D. that is a string and a version that is a number
and then from this we're going to return a promise that is going to resolve with either a ticket doc
or no.
That's how we would express that will either actually find a ticket document or we won't find anything
matching this idea and version criteria.
So that would be our invitation for the return type now to actually implement this method.
We'll scroll down a little bit.
We already went through this process with the build method.
All we have to do is add a new function to the statics object so I'll add in ticket schema that statics
that bind by event and we'll write out our implementation so this will take that same kind of data object
or event object whatever we want to call it all that matters is that it has an I.D. that is a string
and a version that is a number then inside of here all we're really going to do is run the same query
we had just put together inside of our listener so I will return ticket not find one.
We're gonna look for underscore ideas equal to event thought i.e. and a version equal to version minus
one or event dog person
and that should be it so I'll say this file I'm then going to go back over to our listener and now we
can clean up this query right here and hide away these kind of nasty details they're going to turn this
entire thing into a weight ticket dot bind by event and I'll pass in that data object like so
what we should probably do another quick test.
So going to save this.
And once again go to the process of creating a ticket and updating it.
Alternatively we could just try to make another update to the ticket we had made an update to just a
moment ago.
I think that would actually be the best because now we can actually test make sure everything works
with incrementing version numbers as well.
I've still got the previous ticket I had created.
Actually no.
I don't personally because I just deleted all my tickets in the last video.
Too bad for me but for you absolutely you can try to make the same post request and then go back over
to scaffold and make sure that everything got processed without any errors.
So for me personally I don't have to create very quickly a new ticket but the idea and make my update
and I'll make a second update just so it's similar to what you're doing now I should have to update
that I've been processed successfully I go back over the scaffold I will see down here.
Fantastic.
I got a message received to get created and then a ticket updated and a ticket updated and very critically
I don't see any errors which means everything still works as expected.
Well all right.
Well this is definitely good improvement it's something that I think will probably carry through to
other scenarios where we need to select a record by its version as well so take a pause right here if
there's one other thing I want to mention around this implementation in just a moment.