Skip to content

Conversation

@aaronburtle
Copy link
Contributor

@aaronburtle aaronburtle commented Feb 1, 2023

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 RuntimeConfigValidator once 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 sqlmetadataprovider with 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 the source.fields, and target.fields information 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.

image

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.

Copy link
Collaborator

@Aniruddh25 Aniruddh25 left a 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

Copy link
Collaborator

@Aniruddh25 Aniruddh25 left a 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 :)

@aaronburtle aaronburtle merged commit 23ec3a5 into main Feb 3, 2023
@aaronburtle aaronburtle deleted the dev/aaronburtle/LoggingRelationshipColumns branch February 3, 2023 23:15
@aaronburtle aaronburtle self-assigned this Feb 3, 2023
@aaronburtle aaronburtle added improvement Let's make this better usability Make the APIs more user friendly with better exceptions labels Feb 3, 2023
@aaronburtle aaronburtle added this to the Jan2023 milestone Feb 3, 2023
@Aniruddh25 Aniruddh25 linked an issue Feb 4, 2023 that may be closed by this pull request
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

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

Log identified relationships columns DAB Logging

5 participants