Eagerloading when deserializing collections

[Eskeee]

Hey! Just stumbled upon some weird behaviour regarding the deserialization of collections.
When a collection, of models, gets deserialized I would expect the former eagerloaded relations to be loaded again - just like a single model. However that doesn't occur. Do you think this is by design?

Restoration of collections
Restoration of a single model

If it is not by design, you'll experience a nice edge case if you have disabled lazy-loading:

1. Serialize a collection with only 1 model with eagerloaded relations
2. Restore the collection and you'll see the relations loaded again :)

Why? Prevention of lazyloading is only enabled if you have more than 1 entry in your collection. I understand the choice, but doesn't nicely reflect that we don't want any lazyloading even though it corresponds the same.

[macropay-solutions]

See \Illuminate\Queue\SerializesModels Illuminate\Queue\Attributes\WithoutRelations
When that Attribute is used the relations are not serialized.

[Eskeee]

This is not used

[dxnter]

This fix was merged and will be available in 13.x

#58477

[dxnter]

Nope that's valid. If they were originally loaded with constraints, the constraints are lost on deserialization. That's been a pre-existing limitation that also affects single models though and is out of scope for this specific fix.

[marius-ciclistu]

If it's documented, then it is fine.

[marius-ciclistu]

Could the builder be serialized instead of the collection to solve this issue? If the data is not serialized anyway and the DB is the data source.

[dxnter]

Serializing the builder won't work because query constraints are typically closures, and closures can't be serialized. Even with SerializableClosure, the constraints aren't retained on the model after query execution. They're used and discarded.

What could work is storing the relation data itself during serialization and restoring it directly with setRelation() instead of calling loadMissing(). For collections, you'd key the relation data by model ID.

On deserialization, instead of re-querying with loadMissing(), you'd restore the stored data directly. This would preserve whatever was originally loaded (including constrained results) while still fetching fresh base model attributes from the DB.

The trade-off is larger serialized payloads and potentially stale relation data, but that's the only way to preserve constraints without significant changes to how eager loading works.

[Eskeee]

Thanks for addressing the issue and submitting the PR :D I wanted to clarify before hand if it was actually by design 🚀