[Feature] Adapters Model Configuration Snowplow Tracking

[colin-rogers-dbt]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt-adapters functionality, rather than a Big Idea better suited to a discussion

Describe the feature

Since it's inception dbt Core has not given a great deal of thought to adapter specific telemetry. This poses a challenge for us in tracking feature adoption and assessing the impact/risk of making changes.

What we propose is to expose a new method in the base adapter that accepts a RelationConfig and returns an object that conforms toRelationTrackingInfo protocol (tentative name) which details the standard set of fields we want to know about all relations as well as the adapter specific information relevant to that relation. By default this method would return just the basic fields and individual adapters could override to return more specific information.

This method would be invoked here by dbt-core so this does not require direct integration with snowplow itself.

Next step is to flesh the design of this out and implement a rough proof-of-concept.

Describe alternatives you've considered

No response

Who will this benefit?

No response

Are you interested in contributing this feature?

No response

Anything else?

No response

[aescay]

@colin-rogers-dbt @VersusFacit just want to double check that I'm tracking this right:

1. we'll be creating an object via the RelationConfig (likely in the final form of a json blob) that has relation information in a standardized structure which will be sent out as part of the invocation event payload (maybe in one of the specific contexts?)
2. we can then customize each adapter's set of configs that conform to the needs of each adapter

If the above is true, great! As we get deeper into the design I'd love to be looped in just to know how the data's going to turn out. Also happy to be a sounding board if you want to jam on anything while in this process.

My only flag here is that if we have relation config defaults that we think are universally important (or more generally, universally true) is there a way to make sure adapters can't override this? Just to make sure our community created adapters don't accidentally drop these and/or can deviate from the standard. I will admit though that I'm not entirely sure what the defaults might be cause I think most of the foundational stuff are things we already have tracking in some form today, so I understand that this part might be moot.

Thank you in advance for all the work on this 🙏

[VersusFacit]

Gathering alignment from Michelle / Andrew as part of this work.