Model binding with a primary key containing the table name doesn't work correctly

[royduin]

Description

I'm getting an error when Livewire is making requests with changes:

Missing required parameter for [Route: issue] [URI: issue/{issue}] [Missing parameter: issue]

And when I look into this it's caused by the primary key on the model which includes the table name:

protected $primaryKey = 'issues.id';

When I remove the scopes which require this as the joined tables also include an id column and remove this custom primary key it's working.

Exact steps to reproduce

Create a model with the table name in the primary key, for example:

class Issue extends Model
{
    protected $primaryKey = 'issues.id';
}

And use that model in a component:

class Issue extends Component
{
    public App\Models\Issue $issue;
    public $something = null;

    public function render()
    {
        return view('livewire.issue');
    }
}

And bind something to $something in the view:

Issue: {{ $issue->id }}
<input type="text" wire:model="something"/>

Now type something in the input.

Stripped-down, copy-pastable code snippets

Context

• Livewire version: 2.4.2
• Laravel version: 8.36.2

[PH7-Jack]

This is not a livewire bug, i created a pr to solves it on laravel

[driesvints]

The actual issue here is that you shouldn't define the table on the primary key. I don't know why you're doing that?

[GrahamCampbell]

There is no bug. Your primary key value is invalid. You must write:

protected $primaryKey = 'id';

[royduin]

So if you want to join a table (from for example a (global) scope) and both tables have an id, what should you use then?

Issue::find(1)

Will cause issues because both tables have an id. I could write that more explicit with for example:

Issue::firstWhere('issues.id', 1)

But implicit route model binding won't work. That's why I added the table name to $primaryKey

[driesvints]

The first example should never clash with a global scope issue. Most likely you're applying joins in a global scope that you shouldn't be doing in the first place. That'll indeed cause the issues you're experiencing.

[royduin]

Using multiple subselects on the same table for now, less efficient in comparison with a join but no conflicts.