Repository navigation
Fix: Use only the requested relationship's FKs when joining an entity with multiple relationships to the same target - #3893
Conversation
… with multiple relationships to the same target Signed-off-by: ShryukGrandhi <85529990+ShryukGrandhi@users.noreply.github.com>
|
Azure Pipelines: There may be pipelines that require an authorized user to comment /azp run to run. |
|
ShryukGrandhi please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
There was a problem hiding this comment.
🟡 Changes recommended
Regression coverage is missing for the linking-object scenario, including verification that relationship filtering preserves the requested foreign keys, linking-table join, and parent-correlation predicate while excluding the other relationship.
1 open issue
What changed in this PR
Fixes relationship join generation for #3849 by selecting only the requested relationship’s foreign keys when multiple relationships target the same entity.
Changes:
- Passes the relationship name into related-entity join generation and filters out other source-side relationships.
- Adds parameterized regression tests verifying that
authorandeditorrelationships each use their own foreign key.
| File | Description |
|---|---|
src/Service.Tests/UnitTests/BaseSqlQueryStructureHelperTests.cs |
Adds regression coverage and updates the existing helper call. |
src/Core/Resolvers/Sql Query Structures/BaseSqlQueryStructure.cs |
Filters join foreign keys by the requested relationship name. |
Review effort: Balanced
| if (foreignKeyDefinition.SourceEntityName == EntityName | ||
| && foreignKeyDefinition.RelationshipName != relationshipName) |
…arget Signed-off-by: ShryukGrandhi <85529990+ShryukGrandhi@users.noreply.github.com>

Why make this change?
Fixes #3849
When an entity defines more than one relationship to the same target entity (for example
production_countryanddefault_load_country, both pointing tocountry), the generated join for either relationship includes the foreign key predicates of all of them:So the nested object comes back
nullunless both FK values happen to be equal. This is the same bug reported earlier in #1718 and #2223.What is this change?
AddJoinPredicatesForRelatedEntitylooks up the foreign key definitions by(source entity, target entity), and that list contains the definitions of every relationship between the two entities. EachForeignKeyDefinitionalready carries theRelationshipNameit was created from, so the method now takes the relationship name (already available asfkLookupKey.RelationshipNameinAddJoinPredicatesForRelationship) and skips definitions that belong to a different relationship of the same source entity.Definitions that come from the target entity's side of the relationship (the fallback lookup) have a different
SourceEntityNameand are unaffected, as are self-joins, which already use the per-relationshipRelationshipToFkDefinitionlookup. This covers both nested selection and nested filters, since both go throughAddJoinPredicatesForRelationship.How was this tested?
Added
AddJoinPredicatesForRelationship_MultipleRelationshipsToSameTarget_UsesOnlyRequestedRelationshiptoBaseSqlQueryStructureHelperTests. It sets up aBookentity with two relationships (author,editor) toAuthorand checks that each one produces a single join predicate on its own source column. Before the fix both cases failed (2 predicates instead of 1). After the fix the whole test class passes (23/23).I couldn't run the database integration suites locally.
Sample Request(s)
With the config from the issue:
{ product_grades { items { name production_country_id production_country { id name } } } }now returns
production_countryfor rows whereproduction_country_idanddefault_load_country_iddiffer.