-
Notifications
You must be signed in to change notification settings - Fork 36
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
Add adapter telemetry method for core model run snowplow event. #328
base: main
Are you sure you want to change the base?
Conversation
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
Proof of operation for fallback method (i.e. adapter does not override) Note adapter_details is |
|
||
|
||
@dataclass(frozen=True, eq=False, repr=False) | ||
class AdapterTrackingRelationInfo(FakeAPIObject, Hashable): |
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 is an interesting case to me: should this actually be considered a "contract" like AdapterResponse
or is it tied to the concept of a relation (i.e. the thing it's tracking)? If the former we should probably put it in it's own module in dbt/adapters/contracts
. I think there's an argument for both so curious what others think
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.
So just putting this forward -- I originally had it as a contract. Then it ran into "can't instantiate protocol" errors. So I'm not sure it should be a contract on that alone!
To me, I had it as something related to the object it's related to because I think in terms of object traits a lot :)
Is this unit test-able? |
@@ -1743,6 +1746,15 @@ def capabilities(cls) -> CapabilityDict: | |||
def supports(cls, capability: Capability) -> bool: | |||
return bool(cls.capabilities()[capability]) | |||
|
|||
@available | |||
@classmethod | |||
def get_adapter_run_info(cls, config: RelationConfig) -> AdapterTrackingRelationInfo: |
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.
RelationConfig
doesn't feel like the correct type. I would have guessed this is some version of NodeConfig
.
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.
I don't have a good handle on the differences here. When I did introspection, we are passing in a RelationConfig
. I bet I'm missing some appreciation of all these different Config objects and perhaps I was "lead on" by the suggestion for RelationConfig
in the original ticket. If you feel strongly on this type, please do offer your thoughts here! I'm actively learning here.
resolves #301
docs dbt-labs/docs.getdbt.com/#
Problem
We need a way to expose adapter telemetry for our internal product adoption analytics.
Solution
The base adapter provides a simple method which is used in dbt core and its tracking system. This method will be overwritten for each adapter that we wish to collect telemetry for.
Checklist