Beautiful.
And once we're done setting up day job functionality before we move on and start checking for permissions,
I also want to show you the alternative approach because you might have some situations where that is
actually the route that you want to take.
Now, let me tell you right away that the video is optional.
I'm adding this only to showcase multiple approaches.
And like I just said, there might be a situation where you have a different set up.
So not set up that we currently have the alternative approach is actually going to be the route that
you'll need to take.
And I also know that I will get these questions.
In course, you and I so might as well set up the video and let's do it this way.
Or first, we'll set up everything in the job and then I'll cover the differences.
So here's what I want to do.
Where we have the company in position for the time being, we'll leave it the way it is.
We'll check for position and company.
Pretty much the code stays here, same when we look for a job.
If it doesn't exist, then we throw the error.
And yes, eventually we'll check for permissions.
But instead of find one and update, here's what I want to do since I have access to the job one by
one.
I'll update the properties.
I'll go with position, the position and companies equal to company, and then we can go with a weight
and job that's safe.
So let's try it out, and then I'll cover why you would want to go with this approach.
So let's go to jobs controller.
First thing, yep, I have company in position, so that stays the same.
Now I will revert back to update jump.
So come on this one out.
And then let's go with job, like I said, the first property is the position, and then that one will
be equal to a position.
Let's copy and paste one too many and then I'll set up two cursors.
And in this case, we're going to go with a company one.
Let's save it.
And before we go any further, let's go and wait and then job and save.
So let's save the job.
And then in here, since I don't have updated Java anymore, I'm just going to go with job.
But again, eventually I will revert back to this set up anyway.
So let's go back to the postman.
And let me check all the jobs senator over here.
Looks like I have, Google added.
That's the last one, and I just need to update.
So I'm going to go.
Not with Google added.
This is going to go back to the Google one, and at the moment, I'll also remove the random one.
Let's save it.
Let's send it.
And it looks like everything is working.
So now let's talk about the differences with these two approaches.
First, what we need to understand is that the reason why you would want to go with this one.
Instead of find one and update is the simple fact that when it comes to find one and update, it does
not trigger the hook.
Now as you are looking at it, you're like, What are you talking about?
We don't have the hook in here.
And you're correct.
But you might have the situation where you do have the hook in your model.
And if that is the case, if you use this, find one and update.
And let's say you have some kind of functionality that runs in that, OK, well, it's not going to
trigger the hook altogether.
And clearly discussed that when we talked about the hooks in the user one.
So when we were dealing with the password.
So if you need to jog your memory, please go back to those videos.
So that's the first thing you need to remember that if you do have some kind of setup.
Where you will be depending on those stocks in model venues, you'll have to go with this approach because
this one will trigger the hook.
Now what is the gotcha over here?
Well, keep in mind that we're only updating the property, correct?
So first of all, you will have to pull them all out from the rack that body in order to update them.
So one by one, you'll have to set them up.
Otherwise, I mean, you can pass the data, but it's not going to update the job.
So it may showcase that I'm going to go back to my post, man once say that I'm going to send back the
job education side, job location, and let's set it equal to a Mexico.
And now let me ask you a million dollar question.
You think in my response, job location is going to be my city or it's going to be Mexico.
Of course, the answer is my city.
Why?
Well, because to update the property here now.
So for every property, we'll have to pull it out from the dead body.
First of all, you have to send it.
And this is the case where, again, remember from the front end, we're sending all of them at the
end of the day.
Because we have them already inputs, so it might look a little bit and overexaggeration since we're
just this thing going off in a postman right now.
Keep in mind that, yes, of course, it also depends how you set up the front then and in our front,
and we're sending all the properties regardless.
Hopefully, that is clear.
And now let me grab here the job location and I want to set it up here as well.
So pretty much for every property that you have in the job model or whichever model you have.
Yes, you'll have to set them up one by one.
Unlike previously where we just updated the property that we're posting, hopefully about a square,
and I'll let me change this one around where I'm going to go with job and location.
Of course I'm Mr Rumpole, but should be job, location, like show.
And also, we need to keep in mind that if, for example, we decide not to send any value and if we
don't have on a property the default one, this will trigger the error.
So let me show that first I'm going to go back to the man on Senate, and once we send the request,
we should get back to Mexico.
But I think I know where is this you?
Yep.
Of course, I wasn't particularly bright and I updated, they read me.
So we need to go back to the day job and we need to pass in there.
So go job, location and land.
Copy and paste.
And we're looking for this value over here as well.
So let's go over here with job and location.
Let's save it.
Let's test it out one more time.
And once we send it, everything is correct.
And again, let me showcase something where if I'm not going to pass the job location altogether when
it comes to find one and update, this is not going to be an issue.
If, for example, I'm going to go back to a job and where I have the location, I'll remove the default
one, then you'll see that right away.
This will trigger here.
So let me remove the default sitter and let my Senate.
And right away you will notice path job location is required.
Again, it's not going to be the case with fine when I'm up.
So like I said, I will revert back to find one and update since I don't have any hooks in the job and
you'll see how everything works.
So let me take this one on commented.
I will add check permissions because that is something that we'll work on in a second.
And now we want to send back the update and job.
And even if I don't have that before them will notice that once we send and in this case, let's just
go with add it just so we can see that we're actually editing something, you'll notice that we still
have that previous Mexico one.
And hopefully this makes it clear where we have multiple approaches.
So with one, we trigger the hooks with the find one and update we don't.
So if you have some functionality that depends on on one, you'll have to go with second approach.
But yes, when you use this approach, first of all, you'll have to make sure that the properties exist.
Otherwise, if, for example, you're not passing the property and setting equal in the object, then
there's going to be no update.
And second, if you don't have the default values and in the model, this actually is required when
you'll get the matter.
Why?
Well, because if I have here the job application, I'm pulling it out of that body.
And if it's not provided with the request, this one will be undefined.
And then I'm trying to set undefined where actually I'm looking for some kind of value.
Keep that in mind.
And now we can start working on check permissions functionality.