Load() and with() functions act inconsistent when using relationships inside relationships

[TylerGauntlett]

• Laravel Version: 7.19.0
• PHP Version: 7.3.20
• Database Driver & Version: MySQL 8.0.20

Description:

Laravel allows using relational values inside other relations. This can be useful when applying additional where() clauses to a relation based on the id field from another relation. Additionally, if you wished to log something about another relationship, this can also be a use case.

Using the framework provided with() or load() functions, the results of a relationship inside another relationship become inconsistent when compared to its non-eager loaded counterpart.

When with() or load() is not used, $this inside a relationship contains all concrete model properties and values. However, when with() or load() is applied, $this is only a class instance, containing no model properties. The result is any relationships inside another return null ONLY when eager loading is applied.

Steps To Reproduce:

Schema:

tasks

• id
• group_id
• team_id

groups

• id

teams

• id

Models:

class Task extends Model
{
    public function group()
    {
        dump($this->team);

        return $this->hasOne(Group::class, 'id', 'group_id');
    }

    public function team()
    {
        return $this->hasOne(Team::class, 'id', 'team_id');
    }
}

class Group extends Model
{
}

class Team extends Model
{
}

Examples

Working Example

$task = \App\Task::query()->first();

dump($task->group);

// Result dumps `$task->team` from inside `team()`
// then `$task->group`

Not Working Examples

$task = \App\Task::query()->with('group')->first();

dump($task->group);

// Result dumps null from inside `team()`
// then `$task->group`

$task = \App\Task::query()->first();

$task->load('group');

dump($task->group);

// Result dumps null from inside `team()`
// then `$task->group`

[staudenmeir]

This can be useful when applying additional where() clauses to a relation based on the id field from another relation.

What constraint would you add in this example?

Eager loading fetches the groups of multiple tasks with a single query and doesn't allow you to have individual constraints per task.

[TylerGauntlett]

@staudenmeir The long answer to my exact use case is as follows:

Code Snippets

class User extends Authenticatable
{
    protected $connection = 'default';

    public function externalGroup()
    {
        return $this->belongsTo(ExternalGroup::class, 'group_id', 'group_id');
    }
}

class ExternalGroup extends Model
{
    protected $connection = 'non_default';
}

class Thing extends Model
{
    protected $connection = 'non_default';

    public function task()
    {
        return $this->hasOne(Task::class, 'id', 'task_id');
    }

    public function primaryTask()
    {
        return $this->hasOneThrough(
            Task::class,
            GroupTask::class,
            'task_id',
            'id',
            'task_id',
            'primary_task_id'
        // auth()->user()->externalGroup does not work as intended
        )->where('group_tasks.group_id', auth()->user()->externalGroup->id);
    }
}

class Task extends Model
{
    protected $connection = 'non_default';

    public function scopePrimaryTasksByThing()
    {
        $taskIds = app(Thing::class)
            ->query()
            // Eager loading here causes the problem
            ->with('primaryTask')
            ->get()
            ->pluck('primaryTask.id');

        $query->whereIn('tasks.id', $taskIds->toArray());
    }
}

class TaskController extends Controller
{
    public function index()
    {
        return app(Task::class)->query()->primaryTasksByThing()->get();
    }
}

Schema:

• users
  • id
  • group_id
• things
  • id
  • task_id
• tasks
  • id
• groups_tasks
  • id
  • task_id
  • primary_task_id
  • group_id
• external_groups
  • id
  • group_id

Overview:

• The User is using the default connection
• The GroupTask, Thing and ExternalGroup are using a different connection
• Every Thing has a Task associated via the task_id
• Additionally, every Thing has a primaryTask, which is determined using the groups_tasks table in combination with the ExternalGroup's id
• The auth()->user()->externalGroup->id is needed in the where() clause
• When eager loading is removed from scopePrimaryTasksByThing, auth()->user()->externalGroupperforms the correct query (ie with the where group_id = ?)

Problem:

• This has slightly different behavior than the null behavior described above. Instead, this does a select * from external_groups limit 1 without a where clause applied when calling auth()->user()->externalGroup
• I think the core problem is still the same/similar as described above though

Work Around:

• My current work around is loading externalGroup on the auth()->user() model prior to performing the query in scopePrimaryTasksByThing
• This work around is specific to the auth()->user() though and would not work for normal models

Example:

public function scopePrimaryTasksByThing()
{
    // This line was added
    auth()->user()->load('externalGroup');

    $taskIds = app(Thing::class)
        ->query()
        // Eager loading here causes the problem
        ->with('primaryTask')
        ->get()
        ->pluck('primaryTask.id');

    $query->whereIn('tasks.id', $taskIds->toArray());
}

[staudenmeir]

We had a discussion about this behavior recently: #33266

I think the core problem is still the same/similar as described above though

The underlying cause is actually different.

This work around is specific to the auth()->user() though and would not work for normal models

What do you mean by "normal models"?

[TylerGauntlett]

The underlying cause is actually different.

Interesting. Thanks for the info.

What do you mean by "normal models"?

By "normal models" I just mean models that don't have global helper functions. I originally did not see an easy way to solve this if I were using a relationship on a model that didn't have a global helper like auth()->user(), but the other workarounds you post seem applicable to that situation #33266 (comment)

[taylorotwell]

I'm not sure I would categorize this as a "bug" at this point. It seems to be something we just didn't anticipate or plan to support.