When a Laravel Job is dispatched that takes an Eloquent Model as an argument in the constructor, you can use the SerializesModels trait which will only serialize the model identifier. When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database (docs). Taylor also announced that in Laravel 5.3, you will also be able to do this with Eloquent Collections! (link)
So why is it necessary or helpful for the framework to re-retrieve the model values from the DB at run time instead of just serializing the attributes of the given model or collection? Let's use a contrived example to demonstrate.
Let's say that you create a new job called SendWelcomeEmail that will be dispatched from your RegistrationController each time a new user signs up for your application. Ideally we don't want our user to have to wait for the welcome email to be sent when they sign up, so we make our SendWelcomeEmail job push onto the queue instead. To accomplish this, Laravel magic only requires that our job implements the ShouldQueue interface. Great!
Here is where the paths diverge.
Scenario 1: We already have the email address of our user and we pass through the users email to the job's constructor. Something like
$user = User::find(1);
dispatch(new SendWelcomeEmail($user->email));Scenario 2: We decide to pass the entire User model into our constructor and use the SerializesModels trait in our SendWelcomeEmail job. Something like
$user = User::find(1);
dispatch(new SendWelcomeEmail($user));The difference in implementation is nearly indistinguishable, but let's play devils advocate for a minute and see how this might play out.
In Scenario 1, a user signs up, and our job is queued to run. Your application was featured on product hunt this morning however, and you have 100s of emails waiting to be sent in your queue. Your user upon signing up realizes they mistyped their email address, and promptly corrects it in the settings of your app. By the time your queue gets around to the SendWelcomeEmail for this user, the email that was serialized with the job is no longer valid. The user never gets their welcome email and the world stops spinning.
In Scenario 2, all the same steps take place, but when the queued SendWelcomeEmail job finally gets its turn to run, Laravel pulls the latest info for the passed in User, and the email gets sent to the updated email address! Praise be to you almighty dev.
To learn more about Laravel Jobs and utilizing the Queue, check out the amazing Laravel Docs on Queues
but in scenario 2, you have to do an additional database call as it needs to look up the user's details. If you're being hammered by traffic, this is a suboptimal situation. Better to pass the string through, so the jobs need to make the additional calls.