Laravel Model Pruning
This episode is for members only

Sign up to access "Laravel Model Pruning" right now.

Get started
Already a member? Sign in to continue
Playing
06. Mass pruning differences

Episodes

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

Transcript

00:00
We're now going to talk about the difference between prunable and mass prunable. And whichever one you choose depends
00:05
on how efficient you want the deletion process to be, but also which features you want included. So off the bat, if we use prunable, we can go ahead and use this pruning method.
00:15
Because what we do is before we prune, we retrieve that batch or that chunk from the database. So we have the physical models in memory that we can then use to access relationships on and do
00:28
all of that cleanup. However, if we want to mass prune something, we do this directly at the database level, which means that we never actually retrieve
00:37
their model records in memory. So really, if you don't need the pruning method, I'd recommend using mass pruning. Let's take a look at how we do this first.
00:47
So very simply, we just use the mass prunable trait instead. So let's go ahead and just look at our database. We've got 10,168 records. That doesn't matter too much.
00:59
Let's go ahead and run our model prune command. And you can actually see that runs a lot faster, obviously, because what we're not doing is retrieving that data from the database into our Laravel app
01:09
first and then deleting it. We're just performing a query at the database level. And you can see here it works in exactly the same way. So we're just pruning them in the standard way.
01:20
So let's now dive in and actually look inside the prunable trait and see what's happening. So we'll do a little bit of a deep dive to see the difference here.
01:30
So let's go down and we'll forget this pruneAll method, first of all. Let's look at prunable. So that is our method here that throws a logic exception
01:39
if the trait is included and we haven't actually defined this method. So that's an interesting technique to use to go ahead and force us to implement
01:47
this prunable method if we have that on our model. Now, the next one is prune. So here, we call this pruning, which we've already seen over in our deployment model here.
01:57
So that's going to go ahead and do that clear up. And then we're going to go ahead and force delete the current model that we're working with. So let's go up here and have a look
02:06
at this pruneAll method, which gets called with this chunk size. So we start off with going ahead and pulling in with trashed if we have soft delete.
02:15
Now, that's a really important part about this, that if you do have soft deletes, they will still be physically removed from the database. This won't soft delete them.
02:24
It will force delete all of them. And we saw this just down here as a condition where if it does implement soft deletes and we have soft deletes, then we just force delete them.
02:34
And that will physically remove them from the database. So that's something to bear in mind as well. Then we chunk this by the ID. And we go ahead and for each of their models,
02:44
we call the prune method, which we've already seen. That will physically remove it from the database. We increment the total. And we find this model pruned event,
02:52
which is pretty much just to run the console command output that we saw. If we just go over to this and just search for it inside of our app,
03:02
you can see just down here under this prune command, this is going ahead and hooking into this. So let's go ahead and search for that. And you can see it's listening for that event.
03:11
And then it's just dumping this info to the console. That's just purely because we're doing this within a trait and we can't directly output stuff to the console within a trait.
03:20
So that's how this works. By doing all of this, what we're doing and by chunking it is we're retrieving each of their models.
03:26
So we'll get a deployment model for each of these and that will prune it. Now let's head over to our mass prunable trait and see what this looks like.
03:36
So you can see here that this prunable is bringing back our query. But what we're then doing is just going ahead. And if we have a limit, going ahead and limiting that.
03:46
And then down here, we're just directly on the query builder itself deleting. We're not iterating through them or chunking them in any way.
03:53
We're just forced deleting them. So just to give you an example in code, if we just head over to roots and web and just do this somewhere up here,
04:01
this is the difference between saying deployment, where, and then some condition. So I'll just put A equals B, just to keep this nice and short.
04:10
It's the difference between saying get and then delete or get each delete, which will grab these into memory, go through each one and then delete them.
04:21
And it's the difference between that and just saying delete, which will send a query to the database and actually delete these directly.
04:27
So that's the difference between prunable and mass prunable. Like I said, the difference here really depends on whether you need performance
04:36
and if you're using pruning to hook into this life cycle. So really, if you don't need pruning, it's probably best to go for the mass prunable trait. And if you do need that pruning,
04:46
then just use the standard prunable trait so you can hook into this. Hopefully that behind the scenes was helpful to work out what's going on here.

Episode summary

In this episode, we're diving into the differences between the Prunable and MassPrunable traits in Laravel, and why you might choose one over the other depending on your use case.

We start off by explaining that Prunable gives you a chance to do cleanup or run logic on each model before it's deleted. That's because when using Prunable, Laravel actually retrieves each record, lets you work with the model (including relationships), and then deletes it. This is handy if you need hooks into your pruning process.

On the flip side, MassPrunable is all about speed and efficiency. Instead of loading each model one by one, this trait issues a straight-up delete query at the database level—no models loaded into memory, and much faster if you just want them gone with no extra fuss.

We walk through some code examples and look under the hood at how these traits work, including how soft deletes are handled (spoiler: pruning will force delete them, not soft delete). We also check out what happens when you fire off these prune commands and how console output is handled behind the scenes.

The takeaway? Use MassPrunable when you want maximum speed and don't need to run custom logic, but stick to Prunable if you need those model lifecycle hooks. This episode should give you some clarity on how your choice affects performance and your application's behavior.

Episode discussion

No comments, yet. Be the first!