samlev
samlev

Samuel Levy

@samlev

Software architect and consultant, working on PHP/Laravel/Livewire

17 Posts 351 Views

  • No matching results...
  • Searching...

/ 255

In response to @cebozkurt

You could also do this for all requests with middleware:

class WithUserId
{
public function handle(Request $request, Closure $next): Response
{
$request->merge([
'user_id' => $request->input('user_id') ?: $request->user()?->id,
]);

return $next($request);
}
}


This wouldn't override the user id if it was actually set in the request, but would inject `user_id` into the input for each request that passes through it.

265

In response to @lpheller

There are some reasons:

* It adds extra payload if you serialize and you don't need the reference back to the parent.
* Sometimes the inverse relationship can't be guessed (or isn't defined)
* If you're not going to reference back to the parent it adds extra processing time to add the model relationship (e.g. if you have 1000 child models it has to iterate through all of them just to add the reference back, but if you're not using it that's wasted cycles/memory)

The big issue that it solves/solved for me is when permission policies reference a parent model in their permission checks, which can lead to some gnarly n+1 queries that you wouldn't expect.

300

In response to @pascalbaljet

There was discussion in the PR where some people thought that inverse() was confusing. I'm still going to use inverse() because it's more obvious to me, but I can see why Taylor added another name that implies "parent" style relationships (it only applies to `Has*` or `Morph*` relationships)

1

317

Eloquent inverse relations (a.k.a. `chaperone()`) and fixes for serializing circular references became available today with v11.22.0!

I was honestly surprised that these PRs got merged, then shocked to see Taylor showing them off in his keynote at #Laracon, but I'm happy that they're available now!

Time to update a bunch of my projects!

405