[5.4] add ability to define reloaded relationships

[browner12]

Ran into this issue when using Laravel Echo to listen for some broadcast events.

currently when a Model is added to a queue and serialized, the
relationships of the Model are not restored when the Model is
unserialized/refetched from the database.

When you are handling the queued event/job with PHP, it’s not a big
issue. You can either manually load the relationships, or just use them
and they will be fetched when needed.

However, when you are broadcasting the events and listening for them in
Javascript, currently there is no way reload the relationship. This
addition allows us to define which relationships we would like to be
reloaded when the object is unserialized.

Simply add a reloadedRelationships property to your event or job:

class OrderCreated implements ShouldBroadcast
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    /**
     * @var array
     */
    private $reloadRelationships = [
        'order' => ['user', 'lines'],
    ];

   /**
     * @var \App\Order
     */
    public $order;

This will automatically reload the user and lines relationships on the events order property.

This syntax allows us to reload relationships on multiple models, if multiple models exist on the event/job.

I don't really love the name I came up with. Would love some suggestions on it.

[taylorotwell]

In your event constructor could you just do $this->order->load().

[browner12]

I have tried both passing in the Order to the event, and loading the Order relationships in the constructor. Neither seems to work.

Based off of this paragraph in the documentation,

If your queued job accepts an Eloquent model in its constructor, only the identifier for the model will be serialized onto the queue. When the job is actually handled, the queue system will automatically re-retrieve the full model instance from the database.

it looks like it doesn't matter what I do before the model is serialized, because it just refetches after it unserializes the model.

another option I was considering was to look for the loaded relationships on the Model, and then also serialize those a similar way where we store the ID of the related model. this seemed like the simpler solution.

[taylorotwell]

The event has to be unserialized though when "BroadcastEvent" fires which would unserialize the model identifier and pass a real model back into your constructor again so I really think calling ->load() in constructor of the event would work. Can you share the full code where you do that?

[taylorotwell]

I think we need to just make this work more transparently. I don't like having a property for it. We may just want all serialized models to reload their loaded relationships? Not sure. @themsaid

[themsaid]

@taylorotwell yes reloading by default seems more reasonable as you'd expect the object you pass to have the same state.

[browner12]

sorry for the delay on responding to this, was trying to work my way through the process and see where it actually loses the reloaded relationships. You are right, but it makes the new BroadcastEvent it will actually recreate the event, and we could force a reload there, but the issue happens when it then gets thrown onto the queue.

I think you are right, we should expect the state to be identical when we put it into a queue, as when we pull it out, so including the relationships (or more likely an ID) is a nicer way to go.

Would you guys like me to take a stab at this one, or are you guys gonna work on it internally?