-
Notifications
You must be signed in to change notification settings - Fork 296
Logging Column Relationship Information #1164
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
Merged
Merged
Conversation
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
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
requested changes
Feb 3, 2023
Collaborator
Aniruddh25
left a comment
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.
Needs to account for missing foreing keys
Aniruddh25
reviewed
Feb 3, 2023
…github.com/Azure/hawaii-gql into dev/aaronburtle/LoggingRelationshipColumns
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
reviewed
Feb 3, 2023
Aniruddh25
approved these changes
Feb 3, 2023
Collaborator
Aniruddh25
left a comment
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.
LGTM! Thanks for making our logs easy to understand :)
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
improvement
Let's make this better
usability
Make the APIs more user friendly with better exceptions
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.
Why make this change?
Closes #969
To be helpful in debugging as well as understand how the service is behaving, we log the information surrounding relationship columns on a per entity basis. These relationship are made up of Source and Target entities, which have referenced and referencing fields that make up the columns that form the relationship. In the case of certain relationships (many to many), these fields are revealed by a linking object.
What is this change?
On startup, within the
RuntimeConfigValidatoronce we have the information populated, we log the relationship information. This is done by handling a collection of different cases which will cover all of the potential relationships we could have. We iterate through the relationships within the provided config, and then handle the cases where we have a linking object, no linking object but we have the foreign key information, and no linking object or foreign key information.In the first case, the linking object will be referencing the columns that make up the relationship in each of the related entities. We can therefore build up this information from accessing the pair to foreign key map within the
sqlmetadataproviderwith the relationship pair we form with the (source, linking) and with (target, linking). When there is no linking object, but foreign key information is present, we use the same pair to foreign key map but using the relationship pair of (source, target) or (target, source). Finally, when we have no foreign key information present, we can use thesource.fields, andtarget.fieldsinformation directly from the config file.Information with a linking object is then logged in the form of
<entity>: <entity.source.object>(<source.fields>) is related to <cardinality> <target.entity:<target.entity.source.object(<target.fields>) by <linking.object>(linking.source.fields: <linking.source.fields>), (linking.target.fields: <linking.target.fields>).And without a linking object in the form of
<entity>: <entity.source.object>(<source.fields>) is related to <cardinality> <target.entity:<target.entity.source.object(<target.fields>).Before this change
We lack any kind of relationship information logging for entities, tables, and columns.
After this change
We log the relationship information from above.
How was this tested?
Tested manually by starting the service with log level set to debug.
Sample Request(s)
No request needed, simply start the service with log level of debug.