{{ message }}
fix(associations): use custom sourceKey/targetKey in internal belongsToMany associations - #18299
Open
tianyk wants to merge 2 commits into
Open
fix(associations): use custom sourceKey/targetKey in internal belongsToMany associations#18299tianyk wants to merge 2 commits into
tianyk wants to merge 2 commits into
Conversation
…ToMany associations The internal toSource/toTarget (BelongsTo) and manyFromSource/manyFromTarget (HasMany) associations of BelongsToMany never received the custom sourceKey and targetKey options, causing them to fall back to the primary key of the source/target model. When sourceKey or targetKey is not the primary key, any include through these internal associations joins on the wrong column. oneFromSource/oneFromTarget already passed sourceKey, so this aligns the remaining internal associations with the same behavior.
Contributor
Author
|
The 5 failing checks appear to be environment/dependency issues unrelated to this change:
All other checks (MySQL, MariaDB, MSSQL, Oracle, Postgres on Node 18, TS typings 4.6-5.2, lint) passed, and the new unit test is included in the passing |
Contributor
|
LGTM, Thank you for doing this. If you would like to do the v7 PR as well, be my guest. I've been meaning to do it for awhile now but just swamped with work. Otherwise I'll probably whip it up tonight. @WikiRik Looks good to me, even if legacy v6. Could we just drop the Node 10 stuff out of the CI? I really hope no one is using it in prod! |
Member
|
@SippieCup dropping Node 10 is a breaking change, so unfortunately not. The postgres CI should be working again with #18292 |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
What does this PR do?
Fixes the internal
BelongsToManyassociations losing the customsourceKey/targetKeyoptions.When defining
belongsToManywith a customsourceKeyortargetKey(i.e. not the model primary key), the internally created associations fell back to the primary key:toSource/toTarget(BelongsTo) fell back toprimaryKeyAttributeinstead ofsourceKey/targetKeymanyFromSource/manyFromTarget(HasMany) fell back to the primary key instead ofsourceKey/targetKeypaired.toTargetbranch was also missing itstargetKeyoneFromSource/oneFromTargetalready passedsourceKey, so this aligns the remaining internal associations with the same behavior.Example of the bug
Including through
belongsToMany.toTargetgenerated a join on the primary key instead of the custom key:Related issue
Related to #18256 (custom
sourceKey/targetKeybeing dropped in some code paths; this PR fixes the internal-association code path on thev6branch).Test plan
Added a unit test that asserts
toSource/toTarget/manyFromSource/manyFromTargetcarry the customsourceKey/targetKey: