Back

It’s awesome! But I don’t really understand the "chaperone" naming. Glad he left the inverse() alias in there.

1

195

I feel the same, would definitely use inverse().

1

260

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

320

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

/ 1000

Hi there! Great work on this feature. I was just wondering - why couldn’t this just be the default for these Has* relations then?
I didn’t yet fully dig through it, but I can’t think of a szenario where I would **not** use it in the relationship declaration…

1

412

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.

303