-
Notifications
You must be signed in to change notification settings - Fork 274
Removing wrong FK definition #2051
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far, but the "Scenario 2" case mentioned in code comments has no tests exercising those paths. that would help understand those code segments so we can step through debugger in the code.
…/Azure/data-api-builder into dev/agarwalayush/removingWrongFK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good and very thorough, please add an issue to track the addition of integration tests, since while everything looks good, these kinds of cases can be tricky to understand and no doubt in the future having good integration testing will be valuable for preventing regressions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making these changes :)
-
Added few straight-forward suggestions to incorporate.
-
Evaluating whether some of the conditionals in BaseSqlQueryStructure.AddJoinPredicatesForRelatedEntity() determine whether the foreign key definition is valid or not can be taken up as a separate issue. Please open an issue to track.
Apart from these, looks good!
recent iterations added changes which look to address resolved feedback.
/azp run |
Why make this change?
If there is a relationship defined for a (source,target) in the database with right cardinality as
ONE
, we add the relationship in both the directions (source->target and target->source) to the source'sRelationshipMetadata
corresponding to the target entity's entry inRelationshipMetadata.TargetEntityToFkDefinitionMap
dictionary.We do this because the relationship can be 1:1 or N:1. In case of N:1, the first FK (from source->target) would be present. In case of 1:1, either or both of them can be present. But all this is known to us only at a later stage when we collect metadata from the database and actually infer which of the two relationships (or both) is/are valid.
After validating the correct relationship, we don't remove the other relationship which we added earlier. The redundant relationship jadds a redundant
JOIN
condition (I think this is something which is visible in the sql query generated by DAB highlighted in this issue: #1940).What is this change?
The functioning of
SqlMetadatProvider.FillInferredFkInfo()
is changed such that for all the FK definitions present for a target entity in the source entity's definition, the FK definitions for a target entity in the source entity's definition contain:The above is achieved via a call to a newly added method
SqlMetadataProvider.GetValidatedFKs()
which loops over all the foreign key definitions defined for the target entity in the source entity's definition and adds to the set of validated FK definitions:How was this tested?
SqlMetadataProviderUnitTests
for Pg/Ms/MySql for the cases when an FK constraint exists between the source/target entities.Manual Testing
For a nested query like:
where the configuration for Book entity looks like:
the query generated before the fix (in main):
after the fix:
<Observe the removal of redundant join condition in the 4th line in the second query>
Similar observations for MySql:
For pgSql:
(Creating issue here to add a test later:Add test to ensure user provided source/target fields take precedence #2104)
Config:
GraphQL query:

Generated SQL query:
