Onto our last row handler of delete.
Now when a user makes a DELETE request we're not going to actually delete the underlying order.
Instead we're going to update its status over two canceled so remember a order has many different statuses.
We can take a look at them inside of our order file in the models directory.
So we've got order status right there if we do a command click on it.
We'll go to the definition of that.
You know the thing can be created awaiting payment complete or canceled.
So when we say that we're going to delete an order again we're not actually deleting it out of the database.
Instead we're just marking in as canceled now that mind.
Does it still make sense to have this be a DELETE request.
Maybe not really a DELETE request kind of implies that we're actually deleting a resource.
We're not really deleting a resource here.
Instead maybe it would make more sense to make this a put or a patch to say that we are updating a property
and just happens that we are updating the property over to canceled.
So maybe it's not the best to say that this is going to be a delete nonetheless.
It's what we're going to do.
Anyways back over to our editor inside of our roots directory.
We're going to find that delete T.S. file so inside of here the logic we're going to write out is going
to look very similar to what we did back inside of show to make sure that a user is authenticated.
We're going to make sure that we find some order inside of our database.
We're also going to make sure that the user who is making this request owns this order as well.
And that's pretty much it.
After we find that do those checks we can update the order status and we're complete.
So first off couple of imports at the top are going to import order from up one directory models order.
We probably also need that order status enum so we can properly set it to cancel that as well to also
get order status.
We need a couple of different middleware from our common module.
So add in and import for require off from our common module and I think that should probably be it right
now.
So inside the root handler itself I'll apply the require auth middleware then inside the root handler
first are going to pull off the order I.D. off of the request parameters object so we'll get order I.D.
from wrecked dock ramps and then like I just said same thing we just did inside of show Find the order
make sure we found in order.
Make sure the user owns the order.
And then finally apply the update they'll do an order is a wait order that find by I.D. and will pass
in the order I.D. then if there is not an order.
So if we did not find one.
Let's throw a new not found error.
In addition if the order does exist but the owner of the order so the user I.D. is not equal to recurrent
user exclamation dot I.D. then we should also forbid this.
So we'll throw a new not authorized error let's add imports for these two errors up at the top we'll
find our common module and add in not found error not authorized error.
Then after that we'll go ahead and make our update to the order so we're all we really have to here
is update the status.
That's pretty much it.
So order not status is going to be order status dot canceled will then save it and that's pretty much
it.
At the very bottom well then send back the updated order.
Like so if this was really a delete handler we should technically also send back specifically a status
of two a four which indicates that a record was deleted.
So if you really want to follow these delete semantics we should have the two a four there.
Again we're not really deleting a record per say we're canceling it but we're kind of pretending as
though that's kind of a delete.
Again I think maybe I kind of made a mistake here now that I'm going through this stuff really maybe
it would have been made a lot more sense to make this into a patch but this is there.
Let me just be clear this is a really small nit pick on my side super not critical.
You know I'm just going to stop complaining about it.
We'll stick with a delete method and a status of two a four and to say it's good enough all right.
So let's say this we do naturally need to make sure that it all works.
So now that we've got the implementation put together quick pause come back in the next video write
out a quick test or two.