Laravel Model Pruning
Playing
01. Generating some test data

Episodes

0%
Your progress
  • Total: 23m
  • Played: 0m
  • Remaining: 23m
Join or sign in to track your progress

Transcript

00:00
The prunable feature of Laravel Models allows you to clear up old model data based on a condition.
00:06
So for example, if we just head over to the database here, I've created out a fake deployments model and table. There's no other data in here at the moment, we just have this created at date. And of course, pruning things could work with absolutely anything, but let's roll with this example. So you can see I've generated out 10,000 records here, and the created at date is
00:27
decrementing all the way down. So essentially what we want to do with pruning in Laravel is remove some older deployments. So how do we do this? Well, I've already set up all of the logic for this, which is exactly what we're going to be running through in this course. But to actually do this, we can go ahead and use the model prune command over on Artisan.
00:46
So if we run this, just give that a second, you can see we get an output here that goes through all of the records, gets that condition and deletes the records that meet that condition. So my case here, I've done something like older than two weeks. So if we give this a refresh, there we go. Sure enough, we've only got 168 rows. So this can be really helpful by just
01:06
cleaning up old data. It's going to improve the speed of your application if you are accessing these tables. And if you don't need this old data, it kind of makes sense to get rid of it. So that's pretty much what we're doing. We're going to go a little bit more in depth in this course at some of the other things that we can do here, but that's the general idea of it.
01:24
So we're going to go ahead and clear everything out here. And we are going to set up a factory that's going to allow us to generate this fake data so you can play along as we go. So let's go ahead and just clear everything out here and start from scratch. OK, so I've gone ahead and completely cleared this project out. The only thing that we've done
01:42
from a fresh install is just update our database connection settings. And we also have a completely empty database here. So nothing has been migrated at the moment. Let's just go ahead and run the default migrations just to make sure that's all good. And that looks good. So we're going to now create that deployment model along with a factory. And we're going to generate some data. It might
02:02
sound fairly straightforward, but we're going to use a sequence here so we can get that created app date incremented when we create these. If we were to create all of these records in one go to test this, we would end up with the same created app date. So really, we just want a really solid way to generate out some data that we can use to compare the created app date. So let's go ahead and
02:25
just go and make a model here. And we'll use the same example. And we'll generate a migration and a factory at the same time. So in terms of the deployments table, I'm not actually going to change anything about this because this already includes the created app and updated app date. So I'm just going to go ahead and migrate this as it is. So if we just head over now, there we go.
02:47
We just want to fill in this created app date. And of course, in reality, you would have a lot more data in there. Okay, so the next thing is the deployment factory, which once again, we don't really need to touch here because we don't have any other data that we can add to this definition. What I'm going to do is just head over to routes and web. And you can do this in something like
03:06
Tinkerwell. You could do it on the command line with just phpr and tinker. But sometimes when I'm playing around with this, when things get a little bit more advanced, I tend to just do it directly within my web routes and then just run this. Okay, so we want to go ahead and use our deployment model. And we want to grab the factory for that. We're going to go ahead and do this a certain
03:25
amount of time. So let's go for 10,000. And we'll just pull this down. And then we're going to go ahead and just say create. Now let's just take a look at the issue that we get. If we just hit the web route here for this, you'll see that when we come over to the database, all of these created updates are exactly the same. So if we had a condition in here that said delete all of these
03:45
records that fall under this condition, we're just going to end up deleting all of them and we're not going to have an accurate representation of how this works. So let's go ahead and get rid of that table. And instead, let's bring in a sequence to go ahead and deal with this. Now sequence takes in a closure. So we could either do a long closure like this, or we could use a shorthand closure
04:06
like this. And into this, we're going to get a sequence object which contains some details about every single part of this. So obviously, this is going to run 10,000 times. And for each of these, we can modify a column to update this data. So really, what we want to do is just specifically defining the created update. Let me go ahead and just define this as a long closure just so it
04:30
makes a little bit more sense in terms of reading this if you're not used to short closures. So from here, we want to return an array that's going to contain any of the fields in here that we want to include in this sequence. So what we can do is use now, which is a Laravel helper that gives us a carbon object back for the current day and time.
04:49
And we can subtract an hour for every single time we run this. Now what we can't do is this, because what we're going to end up with is just the current date minus an hour. So if it's one o'clock, this would be 12 o'clock. And every single record would be 12 o'clock, which is not what we want. So we want this value to be dynamically generated as part of a sequence.
05:10
So like I said, this sequence object will contain a few properties. And you can dump that out if you want to take a look at it. And one of these is the index. So this will be 0, and then 1, and then 2, all the way up to 10,000, or in this case, 9,999. And that will give us the data that we need. So if we just head over and just give this a refresh again, and we just wait for that to
05:32
finish, and we come over here, you can see the first one here is nine o'clock, then eight o'clock, seven, all the way down into the previous day. And we just have a lot more reliable and real life data to play around with. Okay, so now that we have got our fake data generated, it's time to learn about how we can prune this with Laravel's model pruning functionality.

Episode summary

In this episode, we're setting up some test data so that we can try out Laravel's model pruning feature. First, we take a quick look at what pruning is and why you'd want it – basically, it's an easy way to clean up old stuff from your database, like deployments that are more than two weeks old.

We start with a clean Laravel project and empty database, then run migrations to prep our tables. Next, we build a Deployment model along with its migration and a factory. Rather than just making a bunch of identical records, we implement a clever trick using Laravel's factory sequence method to ensure each record gets a different created_at date. We want some realistic data to test our pruning conditions, so this part is super important!

After generating 10,000 fake deployment records (each with a unique timestamp), we briefly peek at the database to confirm everything looks right. Now we've got our test data, we’re ready to dive deeper into Laravel’s pruning features in the next part. So basically, this episode is all about building the data playground we’ll use for experimenting with model pruning!

Episode discussion

No comments, yet. Be the first!