Job Batching Progress with Laravel
This episode is for members only

Sign up to access "Job Batching Progress with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
12. Clearing up after the batch finishes

Episodes

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

Transcript

00:00
OK, let's do a little bit of tidying up once our full batch successfully completes. First of all, we're going to head over to where we failed this and just get rid of the exception that we're throwing. We want the entire batch to run through.
00:13
And again, we have another callback here, which is then. So this is when everything in the job chain or batch has finished processing. OK, so once again, we get the batch in here if we need it. And what do we want to do in this instance?
00:27
Well, we want to go ahead and just update the server with a couple of additional details, like when it was provisioned. And we want to clear up all the existing tasks that we have. So let's go ahead and do this now.
00:38
And then I'm just going to talk to you about how our batch within our queue actually knows what this server is. We'll dive into the database a bit deeper. OK, so once everything has successfully, and this is really important, successfully
00:51
finished, we're going to update our server and we're going to set the batch ID to null. We don't really need that hanging around. We don't need to read any more information about this batch. So we can just get rid of that.
01:02
So the data isn't hanging around and we're going to go ahead and set the provisioned at date to the current date and time, and then we can go ahead and just delete all the tasks. The only purpose of these being in the database here is so we can keep track
01:15
of them when we're provisioning our server or when we're performing any other actions in this batch. So let's go ahead and say server tasks delete. And of course you can do absolutely anything in here that you need to do.
01:28
Okay. Let's see this action. So let's make sure that we are closing off and rerunning our queue. Let's go over to the database and just get rid of anything in here that we don't
01:36
need, including our job batch, and let's rerun this from the UI. Okay. So we're going to go over, we're going to wait for all of these tasks to run through. So again, we're going to have to wait like 15 seconds for each one of these to go
01:48
through, but once this has finished, we'll go over to our servers table and have a look at what we have in here. So let's just wait for this last one to finish. And once that is complete, sure enough, all of the server tasks have now been deleted.
02:02
If we head over to the server, the batch ID has been set to null and the provision.date has been set to the current date and time when this finished. Okay. So the question now, just to dive a little bit more deeply into this is how does this
02:15
know inside of our queue when we're technically not running this entire thing within one session, know how to access the server. Let's just dive in and see what we have within our job batches. So if we look in here, we've actually got a serialized options field in here.
02:32
Let's just copy everything inside of there, head over and just pull up a new plain text scratch file. What you'll notice is all of the data that we are using within this batch. So everything within that observer is being serialized in here.
02:46
Let's just look for where we are progressing this. So let's search for our progress callback here. You can see that it's basically just listing out all of the code we wrote inside of that batch.
02:57
Now it knows what this server is because that data has been serialized here. So you can see that the model here is the server model and it contains the ID. So every time this is getting run in our queue in the background, we get an ID out, which tells Laravel what it needs to refetch from the database in
03:16
order to do all of these things. So let's go back over to the database and just check out that server. And sure enough, we can see if we pull that out, that has a server ID of 30. So all of this is getting serialized.
03:28
And that means that Laravel can extract all of this model data out to go ahead and perform an action for each progress or when this fails, anything that we're currently doing inside of our code. So that's just how that works in the backend.
03:42
If you have any problems with rehydrating data inside of any of these callbacks, it's likely to do with how this has been serialized. You won't often find problems with this, but if you do see any issues, the serialized data is the place to look to figure out if anything has gone wrong.
18 episodes•1 hr 37 mins

Overview

Let’s tackle how to batch tasks in Laravel, change their state as they complete, and display step-by-step progress in the UI.

Using job batching we’ll create, dispatch and monitor a list of sequential jobs — changing their state using model states. We’ll also take this a step further to allow batch variations based on different tasks, and the ability to easy swap around the order of tasks.

At the end of the course, we’ll set up a UI with Livewire to poll the state of our batch, displaying progress to the user (and if anything goes wrong).

Simply put, if you’re building something that requires step-by-step jobs to be run and you need to display progress to the user — this course covers absolutely everything you’ll need to know.

Alex Garrett-Smith
Alex Garrett-Smith
Hey, I'm the founder of Codecourse!

Episode discussion

No comments, yet. Be the first!