Welcome back to module five. This is less than 5.7. Trigger triggers are commonly used to enforce unique business rules. For example, perhaps after inserting a transactional record, you need to round to a specific precision. That's Ah,
what business management wants to use. For example, a lot of data base applications will have four decimal, six decibels of precision and, on occasion, the business. Use my say, Well, we only want to
decimal places of precision. So let's go ahead and implement that, and you might use a trigger to implement that.
Now they're also commonly used to log events.
When implementing triggers. Try to use strong core code organization wrapped complex code in a procedure that is called by the trigger. Don't just stack endless amounts of code in the trigger.
This is really useful for triggers that are doing multiple things where you have multiple distinct things happening. And if you just stack all that code on top of each other. When someone goes to edit that code, it could be difficult to tell When one action is starting and the old one is ending.
Try to use names that self document for the trigger For example, if you have a trigger on the user table and it's after insert, call the trigger user after insert.
Then when someone sees the trigger just by the title, they have an idea of what's going on or what causes that trigger to fire.
Avoid triggers in the falling scenarios. You don't want to use trails for complex data processing. They aren't ideal in those scenarios. You also don't want to use them in transactions, and my civil won't let you do this, although some other database engines may, you do want to avoid it if you find yourself in that environment
now. With that said, let's go ahead and start implementing a logging trigger.
All right, let's get a trigger implemented. I already have one laid out here. Let's go ahead and walk through what's occurring.
So I'm doing a delimit er change. When we implement this in the migration file, we actually won't need this line or the delimit er switching to occur. I'm going to create trigger users after delete the reasonable name. It's targeting the users table and it occurs after delete.
So after delete on users for each row begin, we're gonna declare an i d.
It's big and unsigned. We want to do our best to use the same data types or the columns that were targeting. So our i d fields are big imagers on signs, so we're going to use that data type. Otherwise, we can get these weird airs if one of the state
structures goes out of bounds for
the data type, like an imager verse a big manager.
So we're gonna set the i d to a selection of the max i d. From logs where school I d equals old school i d. So we're bringing in the school idea of the user that got deleted. And then we're doing a coal ace function police function so that if we get no back, we'll just use zero instead.
we don't get no and said I d equal to know which would fail on the insert.
So once we get the next Max, I d. Plus one back,
we then insert into lochs the values the i. D. The old school i d. The title that the user was deleted. No, for the code because it's not an air code. And then aken caffeinated message user old I d deleted from database
with the created and updated time steps being now.
So let's go ahead and implement that in a migration file.
So I'm in the wagon session Ssh session.
So I'm in the right folder. So we're gonna do PSP artists in
make colon a migration
So the more files you make, the more happy you will be if you, uh, went with good naming structures. If your files don't reflect what's in them and you end up having hundreds of files as an application of balls,
you will not be a happy camper. When none of those fall names describe what's inside the contents, you actually have to look inside them.
folder or that file. So database migrations tree users after the lead.
So when added this one
and I'm gonna go ahead and peak back in my old my old, uh, get g p a function.
I know I need something along these lines. Db unprepared.
Was it a copy paste that in? But I wouldn't delete what I don't need,
and I'm gonna go to my script and I'm going to copy
except I'm not going to get the delimit er's changing.
So go ahead and place this in there.
Now, we have some issues with the single quotes
and to fix that, I'm gonna actually switch these beginning single quotes and ending sequel quotes, double quotes
that should solve that issue.
And I need another one of these.
I need it in down section
and we're gonna drop trigger if exists,
not forget. I semicolons
gonna save it. Now I'm gonna go into our
ssh session and I'm gonna run a PHP artisan.
Okay, it looks like our trigger is created. So let's give a let's go. Make sure it's in our database,
you fresh And sure enough it is
So we can see that the code has been implemented in our DB recession.
So now I need to see the database because when I ran the refresh, it would have wiped the database data. So it's be artisan
because it's a good idea to test, definitely at least test once when you implement a new data structure just to make sure that something doesn't catch you off guard or that you made you might have made some silly mistake because it happens to the best of us.
So it looks like it's seated.
Let's check our logs table.
No doubt in there. We haven't logged anything. Let's go to our users table
and let's delete a random user 95.
Now let's go check our logs table refresh.
And sure enough, we have an idea of zero. Which is fine
because we used a police to select zero. If we get no back school, i d three
title is user deleted and description is User 95 deleted from database, and we can see the time that happened.
So that appears to be working. We are effectively logging when users are deleted,
so that completes this portion of lesson. Let's go ahead and head over to the summary,
and that brings us to the 5.7 triggers summary. We discussed when and when not to use triggers, and then we implemented a logging trigger in our migration falls that logs when users are deleted.
That completes this lesson, and I hope to see you in the next Thank you