When a Laravel Job is dispatched that takes an Eloquent Model as an argument in the constructor, you can use…
When dispatching an object onto the queue, behind the scenes Laravel is recursively serializing the object and all of its properties into a string representation that is then written to the queue. There it awaits a queue worker to retrieve it from the queue and unserialize it back into a PHP object (Phew!).
When complicated objects are serialized, their string representations can be atrociously long, taking up unnecessary resources both on the queue and application servers.
Because of this, Laravel offers a trait called
SerializesModels which, when added to an object, finds any properties of type
Eloquent\Collection during serialization and replaces them with a plain-old-PHP-object (POPO) known as a
ModelIdentifier. These identifier objects represent the original properties
Model type and ID, or IDs in the case of an
Eloquent\Collection, with a much smaller string representation when serialized. When these objects are unserialized, the
ModelIdentifiers are then replaced with the
Models that they temporarily represented.
ℹ️ Curious to know how the
SerializesModelstrait is «replacing» these properties at runtime? Before jumping into the source code, you may want to read the PHP docs for a quick primer on what the reflection API offers.
Because of the SerializesModels trait that the job is using, Eloquent models and their loaded relationships will be gracefully serialized and unserialized when the job is processing.
While this quote from the docs sounds promising, it can be misleading. Here is an example of how a
Model would be represented when serialized.
As you can see, the relation is serialized as
records, which is the name of a one-to-many relation between
Record as it exists on the
User model. However, even though we’re only selecting the
user_id columns and have a limit of 3 records to be returned with the
User model, there’s no mention of which records, which properties, or how many in the serialized representation.
Let’s see what the query log looks like when we unserialize this object.
Wow! We’re selecting all
Record models, in their entirety, associated to the
User! As you can probably imagine, this can cause unforeseen issues for the unexpecting artisan.
Hope is not lost! There are workarounds without having to sacrifice resources on the queue, application, or database servers.
Unload unnecessary relations
If you don’t need the loaded relations to be re-loaded, you can simply call
withoutRelations() on your
Model before it’s serialized.
As you can see, there are no longer any relations that will be loaded when the
User model is unserialized.
Make necessary relations their own property
If the loaded relation is going to be required after the
Model is unserialized you can store the relation (which is an
Eloquent\Collection) as its own property on the object being serialized.
As you can see, the serialized representation of the
Eloquent\Collection specifies what the
Model type is and which IDs need to be retrieved from the database.
Much better! Now that our
Records have been hydrated, we can even set the relation back on the
Model by using the
While it’s recommended to use the
SerializesModels trait on any and all objects that will be queued (or otherwise serialized) it is crucial to be at least aware of its potential pitfalls and shortcomings as well as how to avoid running into them, if not understand how it all works under the hood.