If it's presented as an eloquent driver (i.e. eloquent treats the salesforce API like a database), then you could just use an SQLite database to back those models in tests.
Samuel Levy
@samlev
Software architect and consultant, working on PHP/Laravel/Livewire
• 17 Posts • 351 Views
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.
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.
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)
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!