[9.x] Fix clone issue on updateOrCreate and firstOrCreate #42434
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
#42087 breaks functionality on
BelongsToMany
with a custom pivot table/model forupdateOrCreate()
andfirstOrCreate()
.The current behavior,
is creating an issue in which all columns from the pivot table are applied to
$instance
. This isn't expected behavior in general, but is a breaking change introduced in #42087 when the pivot table has a primary key matching the source model -$instance->id
will end up being theid
from the pivot table, not the target table thefirstOrCreate()
orupdateOrCreate()
is pointing to.The chain of magic
__call
and__clone
methods betweenRelation
,Eloquent\Builder
andQuery\Builder
is a bit hard to follow. This is compounded by the fact that$this->clone()
uses theForwardsCalls
trait to delegate the call intoEloquent\Builder
, returning an instance of that builder instead of a copy of `Relation.(clone $this)
- directly cloning theRelation
to do the$instance
query keeps the pivot table data out of$instance
./cc @trideout